Re: else ladders practice

Bart <bc@freeuk.com> wrote:

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.

If a parser generates parse tree, then you can use it as an
input to actual compiler.  Or you can interpret it.  Applies
to almost any language.

Statically typed or
dynamic.

Normal Lisp data is tagged, so one can use dynamic typing.  But
Lisp also have type declaration which basicaly say to the compiler
"trust me, this will always be an integer" (when needed replace
integer by some other type).  Lisp has a subset which is similar
to Fortran 77: there are arrays, conditionals, loops etc.  Arrays
may be specialized, say so that they can keep only machine integers
or doubles.  Lisp declarations works in similar way as Fortran 77
declarations: they tell compiler to use machine instructions
for specified type.  Difference is that lacking declarations
Lisp will use dynamic typing.  Anyway, it is possible to translate
Fortran 77 into Lisp and speed of resulting code depends mainly
on quality of code generator.

This approach could be used for a lot of different languages,
just many language implementations do not bother with providing
a compiler and then declarations have minor effect.

Imperative or functional.
 
It can also apparently be implemented in a few dozen lines or code.

Few dozen lines is minimal old Lisp implemented in Lisp.  Smallest
implementation in C is very minimal and has about 500 lines.
There is Lisp standard, to implement it you probably need about
20000 lines.  Anyway, modern Lisp implementation are much larger
than your languages.

- 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.

On Linux 'gettimeofday' reliably gives real time with good
resolution.  There is a trouble, as CPU-s now have variable
frequency clock, use slow clock when load is low and switch
to fast clock only under heavier load.  One way to solve it
is to use an utility which pins clock to specific frequency.
Another is to run long enough to switch to higher frequency,
so that lower frequency part does not change much.

--
                              Waldek Hebisch