Path: ...!weretis.net!feeder8.news.weretis.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Tue, 19 Nov 2024 23:41:34 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vhj7nc$2svjh$1@paganini.bofh.team>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>   <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team> <vgdc4q$1ikja$1@dont-email.me> <vgdt36$2r682$2@paganini.bofh.team> <vge8un$1o57r$3@dont-email.me> <vgpi5h$6s5t$1@paganini.bofh.team> <vgtsli$1690f$1@dont-email.me> <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me> <vhins8$1vuvp$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 19 Nov 2024 23:41:34 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="3047025"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 4645
Lines: 80

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