From: bc@freeuk.com   
      
   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   
      
   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   
      
   > And you claim your own tools would be 1000 times faster.   
      
   In this case, yes. The figure is more typically around 100 if the other   
   compiler is optimising, however that would be representations of the   
   same program. A68G is somewhat bigger than my product.   
      
   >  Maybe they   
   > would be.  Certainly there have been tools in the past that are much   
   > smaller and faster than modern tools, and were useful at the time.   
   > Modern tools do so much more, however.  A tool that doesn't do the job   
   > needed is of no use for a given task, even if it could handle other   
   > tasks quickly.   
      
   It ran my test program; that's what counts!   
      
      
      
      
   >   
   > But the crux of the matter, and I can't stress this enough as it never   
   > seems to get through to you, is that fast enough is fast enough.  No one   
   > cares how long cdecl takes to build.   
      
   I don't care either; I just wanted to try it.   
      
   But I pick up things that nobody else seems to: this particular build   
   was unusually slow; why was that? Perhaps there's a bottleneck in the   
   process that needs to be fixed, or a bug, that would give benefits when   
   it does matter.   
      
   (An article posted in Reddit detailed how a small change in how Clang   
   worked made a 5-7% difference in build times for large projects.   
      
   You'd probably dismiss it as irrelevant, but lots of such improvements   
   build up. At least it is good that some people are looking at such aspects.   
      
   https://cppalliance.org/mizvekov,/clang/2025/10/20/Making-Clang-   
   ST-Leaner-Faster.html)   
      
      
   > Of course everyone agrees that smaller and faster is better, all things   
   > being equal - but all things are usually /not/ equal, and once something   
   > is fast enough to be acceptable, making it faster is not a priority.   
      
   My compilers have already reached that threshold (most stuff builds in   
   the time it takes to take my finger off the Enter button). But most   
   mainstream compilers are a LONG way off.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)