From: bc@freeuk.com

On 26/10/2025 11:26, bart wrote:
> On 26/10/2025 06:25, Janis Papanagnou wrote:
>> (This reply is not meant for bart, but rather for all interested
>> folks who should not get repelled by his FUD posts.)
>>
>> On 25.10.2025 00:18, bart wrote:
>>> [...]
>>>
>>> (I remember trying to build A68G, an interpreter, on Windows, and the
>>> 'configure' step was a major obstacle. But I was willing to isolate the
>>> 12 C source files involved, then it was built in one second.
>>>
>>> I did of course try building it in Linux too, and it took about 5
>>> minutes that I recall, using a spinnning hard drive, mostly spent
>>> running through that configure script.
>>
>> (I don't know what system or system configuration the poster runs.
>> I'm well aware that if you are using the Windows platform you may
>> suffer from many things; but the platform choice is your decision!
>> But maybe he's just misremembering; and nonetheless spreading FUD.)
>>
>> I've a quite old (~16+ years old) Linux system that was back these
>> days when I bought it already at the _very low performance range_.
>> With this old system the ./configure needs less than 10 seconds,
>> and the build process with make about _half a minute_ for the whole
>> a68g Genie system. - The whole procedure, from software download,
>> extraction, configure/make, and start an Algol application, needs
>> one minute! (Make that two minutes if you are typing v_e_r_y slowly
>> or have a slow download link. Or just put the necessary commands in
>> a shell file; just did that and it needed (including the download)
>> less than 45 seconds, and ready to run.)
>
>
> The 5 minutes I quoted may have been for CPython. It would be for some
> Linux running under VirtualBox on a 2010 cheapest-in-the-shop PC.
>
> If I try A68G now, under WSL, using a 2021 second-cheapest PC but with
> SSD, I get:
>
>     ./configure   20 seconds
>     make          90 seconds

> Only one minute; impressive! How about this:
>
>    c:\qx>tm mm -r \mx\mm -r qq hello
>    Hello World
>    TM: 0.21
>
> This runs my systems language /from source code/, whch then runs my
> interpreter /from source code/ (ie. compiles into memory and runs
> immediately) then runs that test program.

TBF, all such tests need to be from 'cold'. I don't normally do that,
because in routine compilation, you are building something that was just
edited, or just compiled, just generated, or even just downloaded and
extracted. So any files involved will already be cached.

So the following are after a restart of my PC:

  Build CDECL under WSL (files were extracted before the restart):
     60/56 seconds instead 35/49 seconds for configure/make

  My demo above running both compiler and interpreter from source:
     0.31 seconds instead of 0.21 seconds

  New test of gcc compiling hello.c:
     1 second, settling down to 0.23 seconds on subsequent builds

So gcc on Windows still takes longer longer to build a 4-line C program,
than it takes my tools to build an entire compiler and interpreter.

This further emphasises the mismatch between my own everyday experience
and that of most others here.

To be clear, the speed of my tools is 99% due to massive advances in
hardware over decades, rather than my own efforts; I didn't have to do much!

However all those other tools run on the exact same hardware....

Sometimes it pays to be on the ball, to question everything, and to be
intolerant. Something takes even 2 seconds to some task; it's not a long
time, but ... why IS it taking 10 times as long as necessary?

Paradoxically, huge efforts are expended in getting the fastest possible
code from these large compilers, and sometimes the smallest code.

Well, perhaps it's to try and keep up with users writing ever more
inefficient programs! Maybe that 2-second program would have taken 10
seconds.

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)