Re: else ladders practice

Bart <bc@freeuk.com> wrote:

On 19/11/2024 15:51, Bart wrote:

On 19/11/2024 01:53, Waldek Hebisch wrote:

 

Another example, building 40Kloc interpreter from source then running it
in memory:
 
   c:\qx>tm \bx\mm -run qq hello
   Compiling qq.m to memory
   Hello, World! 19-Nov-2024 15:38:47
   TM: 0.11
 
   c:\qx>tm qq hello
   Hello, World! 19-Nov-2024 15:38:49
   TM: 0.05
 
The second version runs a precompiled EXE. So building from source added
only 90ms.

 
Sorry, that should be 60ms. Running that interpreter from source only
takes 1/16th of a second longer not 1/11th of a second.
 
BTW I didn't remark on the range of your (WH's) figures. They spanned 40
minutes for a build to instant, but it's not clear for which languages
they are, which tools are used and which machines. Or how much work they
 have to do to get those faster times, or what work they don't do: I'm
guessing it's not processing 0.5M lines for that fastest time.

As I wrote, there are 2 different system, if interesed you can fetch
them from github.  Build time is just running make, one (typed
system) was

time make -j 20 > mlogg 2>&1

so build used up to 20 jobs, output went to a file (I am not sure
if it was important in this case, but there is 15MB of messages
and terminal emulator could take some time to print them).
Of course, this after all dependencies were installed and after
running 'configure'.  Note that parallel build saves substantial
time, otherwise it probably would be somewhat more than 6 minutes.

For untyped system it was

time make > mlogg 2>&1

Shortest time was

time make stamp_new_corepop > mlogg3 2>&1

this rebuild only one crucial binary (that involves about 100K wc
lines).  This is mixed language project, there is runtime support in
C (hard to say how much as a single file contains functions for
several OS-es but conditionals choose only one OS), assembler files
which are macro-processed and passed to assembler.  There are
header files which are included during multiple compilations.

My point was that with machines available to me and with my
developement process "full build" time is not a problem.
With typed system normal thing is to rebuild a single module, and
for some modules it takes several seconds (most are of order of
a second).  It would be nice to have faster compile time.
OTOH my "think time" frequently is much longer than this,
so compiler doing less checking could lead to longer time
overall.

So it was hard to formulate a response.
 
All my timings are either for C or my systems language, running on one
core on the same PC.

I do not think I will use your system language.  And for C compiler
at least currently it does not make big difference to me if your
compiler can do 1Mloc or 5Mloc on my machine, both are "pretty fast".
What matters more is support of debugging output, supporting
targets that I need (like ARM or Risc-V), good diagnostics
and optimization.  I recently installed TinyC on small Risc-V
machine, I think that available memory (64MB all, about 20MB available
to user programs) is too small to run gcc or clang.

--
                              Waldek Hebisch