Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Fri, 28 Mar 2025 16:40:52 +0000
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <vs6jeh$31p79$3@dont-email.me>
References: <vrd77d$3nvtf$2@dont-email.me> <vrs2eu$176lu$2@dont-email.me>
 <vrs2r3$1b0ov$1@dont-email.me> <vrs7oi$1e2j7$1@dont-email.me>
 <vrtq62$2unrb$1@dont-email.me> <vru2t0$35frt$2@dont-email.me>
 <vrufju$3i02s$1@dont-email.me> <vrugmo$3ij4s$2@dont-email.me>
 <vrugut$3j3ah$1@dont-email.me> <vruma5$3mvbj$2@dont-email.me>
 <vs0gsh$1en04$1@dont-email.me> <20250326110011.634@kylheku.com>
 <vs25oi$2pqb$1@paganini.bofh.team> <QadFP.1351322$zz8b.870017@fx09.iad>
 <86r02iicl3.fsf@linuxsc.com> <JUzFP.529511$f81.413611@fx48.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 28 Mar 2025 17:40:50 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f2249ba52a7656296d3895e7c323ba37";
	logging-data="3204329"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2WIf744Cx7Bw6E4/xcdy3"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:144y02LHCuSl2lhSHEaYyBfVzXE=
In-Reply-To: <JUzFP.529511$f81.413611@fx48.iad>
Content-Language: en-GB

On 28/03/2025 16:13, Scott Lurndal wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> [...]  I have one
>>> source file that takes almost 7 minutes to compile
>>> when using -O3 on a very-high-end xeon box.  Mostly
>>> buried in the overall compile time when using parallel
>>> make.
>>>
>>> The code could be restructured to compile in a few seconds;
>>> but that would require substantial changes to the rest
>>> of the codebase.   Compiling with -O0 for development
>>> testing reduces the compile time to a few seconds.
>>
>> How long does it take compiling with -O1?
> 
> Using -O1 saves 14 seconds on the long-pole.
> 
> 
> $ time mr -s -j96
>   COMPILE g.cpp
>   BUILD lib/lib_g.so
>   BUILDSO libsim.so.1.0
>   BUILD TARGET sim
> 
> real    14m0.76s
> user    13m52.28s
> sys     0m20.13s
> 
> $ time md -s -j96
>   COMPILE g.cpp
>   BUILD lib_g.so
>   BUILDSO libsim.so.1.0
>   BUILD TARGET sim
> 
> real    13m46.49s
> user    13m42.17s
> sys     0m16.66s
> 
> To be clear, we know that this is ridiculous, the generated
> header file totals 1.25 million lines, including a single
> function with over 200,000 SLOC.   Feature creep, antique
> algorithms, screwed up third-party ip-xact collateral and
> tight development schedules.

So, 13:40 minutes for 1.25M lines? (I assume that header contains code 
not just declarations.)

That would make it 1.5Kloc/second, but it also apparently over 96 cores 
(or threads)? That comes to 16 lines per second per thread.

Yeah, ridiculous is almost an understatment.

That 200K lines in one function looks suspicious. Modern compilers like 
to use SSA in functions, but that can yield huge numbers of temporaries.

 >>> Compiling with -O0 for development
 >>> testing reduces the compile time to a few seconds.

That would need 100x speedup with -O0 (for, say, 8 seconds), but I've 
never seen that. However, it would give 150Klps over 96 threads, which 
is plausible.