From: david.brown@hesbynett.no   
      
   On 30/10/2025 01:36, 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.   
      
      
   No, the bottom line is that this program took longer to build than you   
   expected or wanted.   
      
   Did the build time affect whether or not you use A68G ?  If not, then it   
   does /not/ take too long to build, even on your system.   
      
   Of course you might feel it takes longer than you expect, or   
   frustratingly long - that's up to you, your opinions, and your expectations.   
      
   >   
   >>   
   >> 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?!   
   >   
      
   Try "make -j" rather than "make" to build in parallel.  That is not the   
   default mode for make, because you don't lightly change the default   
   behaviour of a program that millions use regularly and have used over   
   many decades.  Some build setups (especially very old ones) are not   
   designed to work well with parallel building, so having the "safe"   
   single task build as the default for make is a good idea.   
      
   I would also, of course, recommend Linux for these things.  Or get a   
   cheap second-hand machine and install Linux on that - you don't need   
   anything fancy.  As you enjoy comparative benchmarks, the ideal would be   
   duplicate hardware with one system running Windows, the other Linux.   
   (Dual boot is a PITA, and I am not suggesting you mess up your normal   
   daily use system.)   
      
   Raspberry Pi's are great for lots of things, but they are not fast for   
   building software - most models have too little memory to support all   
   the cores in big parallel builds, they can overheat when pushed too far,   
   and their "disks" are very slow.  If you have a Pi 5 with lots of ram,   
   and use a tmpfs filesystem for the build, it can be a good deal faster.   
      
   >> (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!   
      
   Try "time make -j" as a simple step.   
      
   >   
   > 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   
   >   
   > 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), so perhaps 40 seconds   
   > on the PC, suggesting that the underlying Windows file system may be   
   > slowing things down, but I don't know.   
   >   
   > However the same PC, under actual Windows, manages this:   
   >   
   >    c:\qx>tim mm qq   
   >    Compiling qq.m to qq.exe      (500KB but half is data; A68G is 1MB?)   
   >    Time: 0.084   
   >   
   > And this:   
   >   
   >    c:\cx>tim tcc lua.c           (250-400KB)   
   >    Time: 0.124   
   >   
      
   Windows is a fine system in some ways, but it has different strengths   
   and weaknesses compared to Linux.  There are plenty of things Windows   
   handles better than Linux in a very general sense.  Here, however, there   
   are two things that Linux (and all *nix style OS's) does significantly   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)