From: antispam@fricas.org

bart  wrote:
> On 29/10/2025 23:04, David Brown wrote:
>> On 29/10/2025 22:21, bart wrote:
>
>>> It was certainly an issue here: the 'make' part of building CDECL and
>>> A68G, I considered slow for the scale of the task given that the apps
>>> are 68 and 78Kloc (static total of .c and .h files).
>>>
>>
>> I have no interest in A68G.  I have no stake in cdecl or knowledge (or
>> particular interest) in how it was written, and how appropriate the
>> number of lines of code are for the task in hand.  I am confident it
>> could have been written in a different way with less code - but not at
>> all confident that doing so would be in any way better for the author of
>> the program.  I am also confident that you know far too little about
>> what the program can do, or why it was written the way it was, to judge
>> whether it has a "reasonable" number of lines of code, or not.
>>
>> However, it's easy to look at the facts.  The "src" directory from the
>> github clone has about 50,000 lines of code in .c files, and 18,000
>> lines of code in .h files.  The total is therefore about 68 kloc of
>> source.  This does not at all mean that compilation processes exactly 68
>> thousand lines of code - it will be significantly more than that as
>> headers are included by multiple files, and lots of other headers from
>> the C standard library and other libraries are included.  Let's guess
>> 100 kloc.
>
> Yes, that's why I said the 'static' line counts are 68 and 78K. Maybe
> the slowdown is due to some large headers that lie outside the problem
> (not the standard headers), but so what? (That would be a shortcoming of
> the C language.)
>
> The A68G sources also contain lots of upper-case content, so perhaps
> macro expansion is going on too.
>
> The bottom line is this is an 80Kloc app that takes that long to buidld.
>
>>
>> The build process takes 8 seconds on my decade-old machine, much of
>> which is something other than running the compiler.  (Don't ask me what
>> it is doing - I did not write this software, design its build process,
>> or determine how the program is structured and how it is generated by
>> yacc or related tools.  This is not my area of expertise.)  If for some
>> strange reason I choose to run "make" rather than "make -j", thus
>> wasting much of my computer's power, it takes 16 seconds.  Some of these
>> non-compilation steps do not appear to be able to run in parallel, and a
>> couple of the compilations (like "parser.c", which appears to be from a
>> parser generator rather than specifically written) are large and take a
>> couple of seconds to compile.  My guess is that the actual compilations
>> are perhaps 4 seconds.  Overall, I make it 25 kloc per second.  While I
>> don't think that is a particularly relevant measure of anything useful,
>> it does show that either you are measuring the wrong thing, using a
>> wildly inappropriate or limited build environment, or are unaware of how
>> to use your computer to build code.
>
> Tell me then how I should do it to get single-figure build times for a
> fresh build. But whatever it is, why doesn't it just do that anyway?!
>
>> (And my computer cpu was about 30%
>> busy doing other productive tasks, such as playing a game, while I was
>> doing those builds.)
>>
>>
>> So, you are exaggerating, mismeasuring or misusing your system to get
>> build times that are well over an order of magnitude worse than
>> expected.  This follows your well-established practice.
>
> So, what exactly did I do wrong here (for A68G):
>
>   root@DESKTOP-11:/mnt/c/a68g/algol68g-3.10.5# time make >output
>   real    1m32.205s
>   user    0m40.813s
>   sys     0m7.269s
>
> This 90 seconds is the actual time I had to hang about waiting. I'd be
> interested in how I managed to manipulate those figures!
>
> BTW 68Kloc would be CDECL; and 78Kloc is A68G. The CDECL timings are:
>
>   root@DESKTOP-11:/mnt/c/Users/44775/Downloads/cdecl-18.5# time make
>>output
>   
>   real    0m49.512s
>   user    0m19.033s
>   sys     0m3.911s

Those numbers indicate that there is something wrong with your
machine.  Sum of second and third line above give CPU time.
Real time is twice as large, so something is slowing down things.
One possible trouble is having too small RAM, then OS is swaping
data to/from disc.  Some programs do a lot of random I/O, that
can be slow on spinning disc, but SSD-s usually are much
faster at random I/O.

Assuming that you have enough RAM you should try at least using
'make -j 3', that is allow make to use up to 3 jobs.  I wrote
at least, because AFAIK cheapest PC CPU-s of reasonable age
have at least 2 cores, so to fully utilize the machine you
need at least 2 jobs.  3 is better, because some jobs may wait
for I/O.

FYI, reasonably typical report for normal make (without -j
option) on my machine is:

real	0m4.981s
user	0m3.712s
sys	0m0.963s

that is real time is bigger than CPU time, but the difference is
reasonably small.  On bigger project using 'make -j 20' I get
results like:

real    1m1.840s
user    6m5.335s
sys     0m34.691s

In the second case some steps are serial and use only one core,
but on average parallel build is much faster.  Both cases are
full build, using NVE (which has much higher troughput than
SATA SSD).

> On the RPi4 (usually 1/3 the speed of my PC), the make-time for A68G was
> 137 seconds (using SD storage; the PC uses SSD),

AFAIK RPi4 is quad core machine, if yours has enough RAM you could
try 'make -j 5'.

> so perhaps 40 seconds
> on the PC, suggesting that the underlying Windows file system may be
> slowing things down, but I don't know.

As I wrote, something is wrong.  Build should be mostly CPU time,
so it should be almost twice as fast compared to real time that
you gave.

--
                              Waldek Hebisch

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