Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Tue, 18 Mar 2025 20:36:11 +0000
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <vrclfv$396ou$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vr3k67$3a5r2$1@dont-email.me>
 <vr3li9$3bqnp$1@dont-email.me> <vr3php$3di63$2@dont-email.me>
 <vr3qa3$3fua7$1@dont-email.me> <vr3vup$3jjoq$1@dont-email.me>
 <vr4ba0$3tj6e$1@dont-email.me> <vr4emj$3vejc$1@dont-email.me>
 <vr67qo$1inip$1@dont-email.me> <vr6ert$1ob25$1@dont-email.me>
 <vr93a6$3i2s$1@dont-email.me> <vr9bd9$adgu$1@dont-email.me>
 <vr9ir0$gve3$1@dont-email.me> <vr9l30$id99$1@dont-email.me>
 <vrbfrn$2899l$1@dont-email.me> <vrbjme$2bne2$1@dont-email.me>
 <vrc6si$1jquk$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 18 Mar 2025 21:36:16 +0100 (CET)
Injection-Info: dont-email.me; posting-host="35833daf7a617b7c2106f27a6fe8438d";
	logging-data="3447582"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18P49kVkF58Mp63FKc1DX9c"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iX+ISojlhbtqqHh06sTRTXlYaEI=
Content-Language: en-GB
In-Reply-To: <vrc6si$1jquk$1@paganini.bofh.team>
Bytes: 5020

On 18/03/2025 16:27, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:

> Actually 20 lines per per second would be not bad.  Early Turbo
> Pascal was considerd very fast and IIRC did 8000 lines per minute,
> that is about 130 lines per second.

You're probably thinking of early commercial compilers for CP/M and 
MSDOS which were badly ported from bigger machines, disk intensive, and 
took minutes for the simplest programs. (According to reviews in Byte 
magazine.)

I had in mind more sensible, specially written ones like mine, or like 
Turbo Pascal.

>> Something is badly wrong.
> 
> People want compilers to do more work.  The idea is to write
> simple program without doing various speed-enhancing tricks
> and still get good execution time.  Look at functions below.
> 'aref' guarantees that all access are in bounds.  But at
> -O2 gcc compiled code for 'my_sum' is the same as code with
> no bound checking.  Simply, compiler can prove that all array
> accesses are in bound, so it can safely remove checking
> code.  How good is code from your compiler (assuming that
> source code is checking all array accesses)?

I assume you mean that -O2 will inline the aref() call, and then also 
figure out that the check is not needed, or can be hoisted out of the loop?

My compiler will translate everything exactly as written. It will assume 
the programmer will write reasonably sensible code, and not add their 
own bound-checking code, not only per-iteration, but in a separate function!

If you write (or generate) code like this, in the expectation that a 
clever compiler will optimise it out, then you will need such a compiler.

The problem is that gcc-O0 will not optimise either, and it still builds 
20-30 times more slowly than those fast compilers!

(I run a interpreted language with bounds checking. Runtime bounds 
errors on finished programs are incredibly rare. I would not expect to 
need such checks in compiled languages except during development or on 
debug versions.

And especially in examples like yours when you expect to trust the size 
that the array object carries with it.)

I tested a version of your code as shown below, which needs a 1.6GB 
allocaton. Runtimes were:

tcc       4.1 seconds
gcc -O0   3.7 seconds
DMC -o    2.0 seconds   (32-bits)
bcc       1.8 seconds   (my product)
gcc -O2   1.2 seconds   (-fno_inline)
mm        1.1 seconds   (in my language, when aref is a macro)
gcc -O2   0.8 seconds

When you see 4.5:1 between optimised/non-optimised then you know there's 
funny business going on: C code that is written in a manner that will 
rely heavily on optimisations.

-----------------------------

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>

void my_error(void) {
     fprintf(stderr, "my_error called\n");
     exit(EXIT_FAILURE);
}

typedef struct {size_t size; int a[];} my_arr;

int aref(my_arr * t, size_t i) {
     if (i < t->size) {
         return t->a[i];
     } else {
         my_error();
         return 0;
     }
}

long long my_sum(my_arr * t) {
     size_t n = t->size;
     size_t i;
     long long sum = 0;
     for(i = 0; i < n; i++) {
         sum += aref(t, i);
     }
     return sum;
}

int main() {
     enum {n=400000000};
     my_arr* S;
     long long sum=0;

     S=malloc(n*sizeof(n)+sizeof(int));
     S->size=n;

     for (int i=0; i<n; ++i) S->a[i]=i+1;

     sum=my_sum(S);

     printf("N=%d Sum=%lld\n", n, sum);
}