Re: Baby X is bor nagain

On 21/06/2024 20:43, bart wrote:

On 21/06/2024 14:51, David Brown wrote:

On 21/06/2024 15:25, bart wrote:

On 21/06/2024 11:46, David Brown wrote:

On 20/06/2024 22:31, Vir Campestris wrote:

On 17/06/2024 14:43, David Brown wrote:

>
Compilation speed is important to everyone. That's why so many tricks are used to get around the lack of speed in a big compiler, or so many extra resources are thrown at the problem.

>
What "tricks" ?

>
Precompiled headers sprang to mind in about half a second.
>
<https://en.wikipedia.org/wiki/Precompiled_header>
>
Andy

>
These are used primarily in C++, where you often have /very/ large headers that require a significant amount of analysis.  In C, this is not remotely the same scale of problem.  C headers are usually far shorter - and far simpler to process.  (In a quick test on my system, #include <stdio.h> pulled in 792 lines, while #include <iostream> took 28152 lines.)

>
C standard headers are nothing. From 3K to 5K lines between Windows and Linux, last time I looked. That's for all 30 headers.

>
C headers for most other libraries are usually also short, at least compared to C++ headers.
>

(Which is why I think they should just be included anyway.)

>
That would be a terrible idea for many reasons.
>

>
But library headers can be much bigger. I already gave a timing for windows.h, of 1.4 seconds. SDL2, quite a small library compared with some, is still 50K lines, and adds 0.75 seconds compilation per module.

>
I don't know what version of SDL headers I have (it's not a library I have used myself), but there are about 30 headers in the /usr/include/SDL/ folder, totalling some 12K lines (after preprocessing).  Including them all in an otherwise blank C file takes about 40-50 ms to compile - basically, noise.

 I don't trust your figures. How many lines were there /before/ preprocessing? Since if significantly more, all that has to be processed still.
 

There are about 12K lines in my /usr/include/SDL/ folder /before/ preprocessing.  I'm guessing that during preprocessing, some of these will disappear due to conditionals, while some will be duplicated due to the same file included more than once, and other headers will be pulled in from elsewhere.  The end result happens to be around the same, though it is certainly not guaranteed that this would be the case.
I checked versions - it seems this is SDL 1.2.  As I say, I have never used it directly (I guess the headers got pulled in along with some other package).  There could be huge differences between SDL 1.2 and SDL 2, for all I know.

Even at 12K lines and 50ms, that gives gcc a throughput of 0.25M lines per second, something I've never seen on any version of gcc. And if it was 50K lines like mine (just the lines in all the SDL*.h files), then it suggests a throughput of 1M lines per second.

Lines per second is a completely meaningless way to measure compiler speed.  I know you like it, but it makes no sense at all - it's like measuring the productivity of programmers in lines per day.  I expect compilers to chew through C headers far faster than main code, whether or not they do any optimisations.

 

>
Again, this is a decade old PC with spinning rust disk.  A key difference, of course, is that I am using an OS that is suitable for the task.

 I tried it under WSL too (unless that doesn't really count as a suitable OS):

WSL does not, I think, count as a suitable OS in regard to timings and efficiency - it relies on Windows for file and disk access, and either runs processes on the Windows kernel or has virtualisation overheads (I don't know the details of WSL workings).

     WSL         gcc 9.4  -S   0.5 seconds to process #include "sdl.h"
    Windows 11  gcc 14.1 -S   0.7 seconds
 That last is the same OS where my mcc compiler takes 0.08 seconds to process those same SDL*.h files.
 I think you've misplaced a decimal point somewhere.

No.