From: david.brown@hesbynett.no   
      
   On 30/10/2025 13:07, bart wrote:   
   > On 30/10/2025 10:15, David Brown wrote:   
   >> On 30/10/2025 01:36, bart wrote:   
   >   
   >> 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.   
   >   
   >   
   > OK, "make -j" gave a real time of 30s, about three times faster. (Not   
   > quite sure how that works, given that my machine has only two cores.)   
      
   You presumably understand how multi-tasking works when there are more   
   processes than there are cores to run them.  Sometimes you have more   
   processes ready to run, in which case some have to wait.  But sometimes   
   processes are already waiting for something else (typically disk I/O   
   here, but it could be networking or other things).  So while one compile   
   task is waiting for the disk, another one can be running.  It's not   
   common for the speedup from "make -j" or "make -j N" for some number N   
   to be greater than the number of cores, but it can happen for small   
   numbers of cores and slow disk.   
      
   >   
   > However, I don't view "-j", and parallelisation, as a solution to slow   
   > compilation. It is just a workaround, something you do when you've   
   > exhausted other possibilities.   
      
   You moan that compiles are too slow.  Yet doing them in parallel is a   
   "workaround".  Avoiding compiling unnecessarily is a "workaround".   
   Caching compilation work is a "workaround".  Using a computer from this   
   century is a "workaround".  Using a decent OS is a "workaround".  Is   
   /everything/ that would reduce your scope for complaining loudly to the   
   wrong people a workaround?   
      
   Of course this kind of thing does not change the fundamental speed of   
   the compiler, but it is very much a solution to problems, frustration or   
   issues that people might have from compilers being slower than they   
   might want.  "make -j" does not make the compiler faster, but it does   
   mean that the speed of the compiler is less of an issue.   
      
   >   
   > You have to get raw compilation fast enough first.   
      
   Why?  And - again - the "raw" compilation of gcc on C code, for my   
   usage, is already more than fast enough for my needs.  If it were   
   faster, I would still use make.  If it ran at 1 MLOC per second, I'd   
   still use make, and I'd still structure my code the same way, and I'd   
   still run on Linux.  I would be happy to see gcc run at that speed, but   
   it would not change how I work.   
      
   >   
   > Suppose I had the task of transporting N people from A to B in my car,   
   > but I can only take four at a time and have to get them there by a   
   > certain time.   
   >   
   > One way of helping out is to use "-j": get multiple drivers with their   
   > own cars to transport them in parallel.   
   >   
   > Imagine however that my car and all those others can only go at walking   
   > pace: 3mph instead of 30mph. Then sure, you can recruit enough   
   > volunteers to get the task done in the necessary time (putting aside the   
   > practical details).   
   >   
   > But can you a see a fundamental problem that really ought to be fixed   
   > first?   
      
   Sure - if that were realistic.  But a more accurate model is that the   
   cars go at 30 mph - the people will all get there safely, comfortably   
   and in a reasonable time, and if there are lots of people you can scale   
   by using more cars in parallel so that the real-world time taken is not   
   much different.  Your alternative is an electric scooter trimmed to go   
   at 600 mph.  Yes, it is faster for an individual, but is it really   
   /better/?  I'm sure we'd all be pleased if the car went at 60 mph rather   
   than 30 mph, but the speed of the vehicle is not the only thing that   
   affects the throughput of your transport system.   
      
   There is no logical reason to focus solely on speed of one individual   
   part of a large process when there are other ways to improve the speed   
   of the process as a whole.   
      
   >   
   >   
   >>> 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.   
   >>   
   >> Do you think there is a reason why /you/ get fixated on these things,   
   >> and no one else in this group appears to be particularly bothered?   
   >   
   >> Usually when a person thinks that they are seeing something no one   
   >> else sees, they are wrong.   
   >   
   > Quite a few people have suggested that there is something amiss about my   
   > 1:32 and 0:49 timings. One has even said there is something wrong with   
   > my machine.   
   >   
      
   Maybe there /is/ something wrong with your machine or setup.  If you   
   have a 2 core machine, it is presumably a low-end budget machine from   
   perhaps 15 years ago.  I'm all in favour of keeping working systems and   
   I strongly disapprove of some people's two or three year cycles for   
   swapping out computers, but there is a balance somewhere.  With such an   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)