Re: Python recompile

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);
}