Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Fri, 21 Jun 2024 19:43:36 +0100
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <v54hkn$39sdn$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <v4p37r$k32n$1@dont-email.me>
 <v4pei3$m5th$2@dont-email.me> <v523iu$2nli8$4@dont-email.me>
 <v53lmh$34g49$1@dont-email.me> <v53v0q$36coc$1@dont-email.me>
 <v540hi$368vf$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 21 Jun 2024 20:43:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="92723ae92300ac7eb9745c682199eaac";
	logging-data="3469751"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/rITXhlH+Bq85lF5lMiHL8"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kab9O5Fqd0/QV60d1mojiWkDLwY=
In-Reply-To: <v540hi$368vf$2@dont-email.me>
Content-Language: en-GB
Bytes: 5035

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.

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.

My C compiler tells me that in this program:

   #include "sdl.h"

a total of non-unique 112K lines are processed, and 240 non-unique 
#includes are encountered.

If I also tell it to just preprocess, then the result is only 3K lines, 
including standard C headers which SDL includes.

gcc's -E gives me 56K lines, which includes a lot of crap like loads of 
'#' lines, but also huge numbers of intrinsics like:

extern __inline __m128i __attribute__((__gnu_inline__, 
__always_inline__, __artificial__))
_mm_abs_epi32 (__m128i __X)
{
   return (__m128i) __builtin_ia32_pabsd128 ((__v4si)__X);
}

> 
> 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         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.