Re: else ladders practice

On 23/11/2024 16:45, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

FYI, ATM is have a version compiling via Lisp, with bounds checking
on it takes 0.58s, with bounds checking off it takes 0.43s
on my machine.  The reason to look at C version is to do better.
Taken together, your and my timing indicate that your 'cc' will
give me less speed than going via Lisp.  'mcc -opt' pobably would
give an impovement, but not compared to 'gcc'.  BTW, below times
on a slower machine (5 years old cheap laptop):
 gcc -O3 -march=native   1722910us
gcc -O3                 1720884us
gcc -O                  1642328us
tcc                     7661992us
 via Lisp, checking      5.29s
via Lisp, no checking   4.27s
 With -O3 gcc vectorizes inner loops, but apparently on this machine
it backfires and execution time is longer than without vectorization.
 In both cases 'tcc' gives slower code than going via Lisp with
array bounds checking on, so ATM using 'tcc' for this application
is rather unattractive.

Lisp is a rather mysterious language which can apparently be and do anything: it can be interpreted or compiled. Statically typed or dynamic. Imperative or functional.
It can also apparently be implemented in a few dozen lines or code.
Forth has similar claims.
So Lisp being as fast or faster than C is not surprising!

 I may end up using inline assembly, but this is a mess: code for
fast machine will not run on older ones, on some machines
non-vectorized code is faster.  So I would need mutiple versions
of assembler just to cover x86_64.  And I have other targets.
And this is just one of critical routines.  I have probably about
10 such critical routines now and it may grow to about 50.
To get good speed I am experimeting with various variants.
So going assembler way I could be forced to write several
thousends of lines of optimized assembler (most of that to
throw out, but before writing them I would not know which
ones are the best).  That would be much more work than just
passing various options to 'gcc' and 'clang' and measuring
execution time.

Using assembly to get speed is not as easy as it used to be. Most such attempts seem to generate slower code. Only for certain apps such as interpreters, but there you are dealing with a bigger picture than one particular bottleneck.

- most of code is portable, but for timing we need timer with
    sufficient resolution, so I use Unix 'gettimeofday'.

>
Why? Just make the task take long enough.

 Well, Windows 'clock' looks OK, but some old style timing routines
have really low resolution and would lead to excessive run
time (I need to run rather large number of tests).

I've tried all sorts, from Windows' high performance routines, down to x64's RDTSC instruction. They all gave unreliable, variable results. Now I just use 'clock', but might turn off all other apps for extra conistency.

 

BTW I also ported your program to my 'M' language. The timing however
was about the same as mcc-opt.
>
The source is below if interested.

 AFAICS you have assign-op combinations like 'min:='.  ATM I am
undecided about similar operations.  I mean, in a language which
like C applies operator only to base types they give some gain.
But I want operators working on large variety of types, and then
it is not clear how to define them.

A assignment that in C syntax might be written as:
    x op= y;
would be the equivalent of this, when x has type T:
    T* p;
    p = &x;
    *p = op(*p, (T)y);
If 'op' is not defined for operands of T, then it just won't work. (Arithmetic ops won't work on most usertypes, but the language still allows x += y.)
However the IL I use directly supports min/max including augmented assignment (in-place) versions.