Path: ...!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: else ladders practice
Date: Sat, 30 Nov 2024 11:26:41 +0000
Organization: A noiseless patient Spider
Lines: 139
Message-ID: <viespg$1mcnr$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg3b98$3cc8q$1@dont-email.me> <vg5351$3pada$1@dont-email.me>
 <vg62vg$3uv02$1@dont-email.me> <vgd3ro$2pvl4$1@paganini.bofh.team>
 <vgdc4q$1ikja$1@dont-email.me> <vgdt36$2r682$2@paganini.bofh.team>
 <vge8un$1o57r$3@dont-email.me> <vgpi5h$6s5t$1@paganini.bofh.team>
 <vgtsli$1690f$1@dont-email.me> <vhgr1v$2ovnd$1@paganini.bofh.team>
 <vhic66$1thk0$1@dont-email.me> <vhins8$1vuvp$1@dont-email.me>
 <vhj7nc$2svjh$1@paganini.bofh.team> <vhje8l$2412p$1@dont-email.me>
 <86y117qhc8.fsf@linuxsc.com> <vi2m3o$2vspa$1@dont-email.me>
 <86cyiiqit8.fsf@linuxsc.com> <vi4iji$3f7a3$1@dont-email.me>
 <86mshkos1a.fsf@linuxsc.com> <20241128143715.00003565@yahoo.com>
 <86wmglnvic.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 30 Nov 2024 12:26:41 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ac41a7c23ced312f4a6135274646b7ca";
	logging-data="1782523"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+3x+MD7ZsAE/EVwvoR8NyN"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RNEBIbBJoLutY/gZtTZFS5FQxoA=
In-Reply-To: <86wmglnvic.fsf@linuxsc.com>
Content-Language: en-GB
Bytes: 7633

On 30/11/2024 05:25, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
> 
>> On Wed, 27 Nov 2024 21:18:09 -0800
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 26/11/2024 12:29, Tim Rentsch wrote:
>>>>
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 25/11/2024 18:49, Tim Rentsch wrote:
>>>>>>
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>
>>>>>>>> It's funny how nobody seems to care about the speed of
>>>>>>>> compilers (which can vary by 100:1), but for the generated
>>>>>>>> programs, the 2:1 speedup you might get by optimising it is
>>>>>>>> vital!
>>>>>>>
>>>>>>> I think most people would rather take this path (these times
>>>>>>> are actual measured times of a recently written program):
>>>>>>>
>>>>>>>        compile time:       1 second
>>>>>>>        program run time:   ~7 hours
>>>>>>>
>>>>>>> than this path (extrapolated using the ratios mentioned above):
>>>>>>>
>>>>>>>        compile time:       0.01 second
>>>>>>>        program run time:   ~14 hours
>>>>>>
>>>>>> I'm trying to think of some computationally intensive app that
>>>>>> would run non-stop for several hours without interaction.
>>>>>
>>>>> The conclusion is the same whether the program run time
>>>>> is 7 hours, 7 minutes, or 7 seconds.
>>>>
>>>> Funny you should mention 7 seconds.  If I'm working on single
>>>> source file called sql.c for example, that's how long it takes for
>>>> gcc to create an unoptimised executable:
>>>>
>>>>    c:\cx>tm gcc sql.c            #250Kloc file
>>>>    TM:  7.38
>>>
>>> Your example illustrates my point.  Even 250 thousand lines of
>>> source takes only a few seconds to compile.  Only people nutty
>>> enough to have single source files over 25,000 lines or so --
>>> over 400 pages at 60 lines/page!  -- are so obsessed about
>>> compilation speed.
>>
>> My impression was that Bart is talking about machine-generated code.
>> For machine generated code 250Kloc is not too much.  I would think
>> that in field of compiled-code HDL simulation people are interested
>> in compilation of as big sources as the can afford.
> 
> Sure.  But Bart is implicitly saying that such cases make up the
> bulk of C compilations, whereas in fact the reverse is true.  People
> don't care about Bart's complaint because the circumstances of his
> examples almost never apply to them.  And he must know this, even
> though he tries to pretend he doesn't.
> 
>>> And of course you picked the farthest-most
>>> outlier as your example, grossly misrepresenting any sort of
>>> average or typical case.
>>
>> I remember having much shorter file (core of 3rd-party TCP protocol
>> implementation) where compilation with gcc took several seconds.
>>
>> Looked at it now - only 22 Klocs.
>> Text size in .o - 34KB.
>> Compilation time on much newer computer than the one I remembered, with
>> good SATA SSD and 4 GHz Intel Haswell CPU - a little over 1 sec.  That
>> with gcc 4.7.3.  I would guess that if I try gcc13 it would be 1.5 to 2
>> times longer.
>> So, in terms of Klock/sec it seems to me that time reported by Bart
>> is not outrageous.  Indeed, gcc is very slow when compiling any source
>> several times above average size.
>> In this particular case I can not compare gcc to alternative, because
>> for a given target (Altera Nios2) there are no alternatives.
> 
> I'm not disputing his ratios on compilation speeds.  I implicitly
> agreed to them in my earlier remarks.  The point is that the
> absolute times are so small that most people don't care.  For
> some reason I can't fathom Bart does care, and apparently cannot
> understand why most other people do not care.  My conclusion is
> that Bart is either quite immature or a narcissist.  I have tried
> to explain to him why other people think differently than he does,
> but it seems he isn't really interested in having it explained.
> Oh well, not my problem.

EVERYBODY cares about compilation speeds. Except in this newsgroup where 
people try to pretent that it's irrelevant.

But then at the same time, they strive to keep those compile-times small:

* By using tools that have themselves been optimised to reduce their 
runtimes, and where considerable resources have been expended to get the 
best possible code, which naturally also benefits the tool

* By using the fastest possible hardware

* By trying to do parallel builds across multiple cores

* By organising source code into artificially small modules so that 
recompilation of just one module is quicker. So, relying on independent 
compilation.

* By going to considerable trouble to define inter-dependencies between 
modules, so that a make system can AVOID recompiling modules. (Why on 
earth would it need to? Oh, because it would be slower!)

* By using development techniques involving thinking deeply about what 
to change, to avoid a costly rebuild.

Etc.

All instead of relying on raw compilation speed and a lot of those 
points become less relevant.

 > My conclusion is
 > that Bart is either quite immature or a narcissist.

I'd never bothered much about compile-speed in the past, except to 
ensure that an edit-run cycle was usually a fraction of second, except 
when I had to compile all modules of a project then it might have been a 
few seconds.

My tools were naturally fast, even though unoptimised, through being 
small and simple. It's only recently that I took advantage of that 
through developing whole-program compilers.

This normally needs language support (eg. a decent module scheme). 
Applying it to C is harder (if 50 modules of a project each use some 
huge, 0.5Mloc header, then it means processing it 50 times).

I think it is possilble without changing the language, but decided it 
wasn't worth the effort. I don't use it enough myself, and nobody else 
seems to care.