Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.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: Mon, 24 Jun 2024 17:19:58 +0100
Organization: A noiseless patient Spider
Lines: 181
Message-ID: <v5c6bf$10sr7$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> <v4plsk$nn9o$2@dont-email.me>
 <v4pnq6$o4fs$1@dont-email.me> <v4q245$si2n$1@dont-email.me>
 <v4q2rl$sqk3$1@dont-email.me> <v52308$2nli8$3@dont-email.me>
 <v53i4s$33k73$2@dont-email.me> <v53lf7$34huc$1@dont-email.me>
 <v53vh6$368vf$1@dont-email.me> <v54se1$3bqsk$1@dont-email.me>
 <20240624160941.0000646a@yahoo.com> <v5bu5r$va3a$1@dont-email.me>
 <v5c275$vq9k$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Jun 2024 18:19:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b9ae78d5a8a2c8822d3975b378ef6e69";
	logging-data="1078119"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19OLHmqjYpTRA/v87uOaJ1r"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fL6EVARtg5u+/Kl9E0/cGZ+6lbI=
Content-Language: en-GB
In-Reply-To: <v5c275$vq9k$1@dont-email.me>
Bytes: 10120

On 24/06/2024 16:09, David Brown wrote:
> On 24/06/2024 16:00, bart wrote:

>> However, is there any way of isolating the compilation time (turning 
>> .c files into either or .o files) from 'make' the linker?
> 
> Why would anyone want to do that?  At times, it can be useful to do 
> partial builds, but compilation alone is not particularly useful.

It is useful when you are trying to establish the true cost of -O2 
compared to -O0. If including all sorts of extras (why not the time it 
takes to DHL the resulting floppy to a client!) then any figures will be 
misleading.

Anyone reading this thread could well end up believing that applying -O2 
to a compilation only makes gcc 10-15% slower.

> 
>> Failing that, can you compile just one module in isolation (.c to .o) 
>> with -O0 and -O2, or is that not possible?
>>
>> Those throughputs don't look that impressive for a parallel build on 
>> what sounds like a high-spec machine.
> 
> How can you possibly judge that when you have no idea how big the 
> project is?

Because the 'text' (code) size was provided?

>>
>>> If I had were "native" tools then all times will be likely shorter by
>>> few seconds and the difference between -O0 and -O3 will be close to 10%.
>>
>> So two people now saying that all the many dozens of extras passes and 
>> extra analysis that gcc -O2/O3 has to do, compared with the basic 
>> front-end work that every toy compiler needs to do and does it 
>> quickly, only slows it down by 10%.
>>
>> I really don't believe it. And you should understand that it doesn't 
>> add up.
>>
> 
> That's not what people have said.
> 
> They have said that /build/ times for /real/ projects, measured in real 
> time, with optimisation disabled do not give a speedup which justifies 
> turning off optimisation and losing the features you get with a strong 
> optimising compiler.

All the projects I tried except one give a typical speed-up of 2x or 
more at -O0.

The exception was the SDL2 project (which now gives timings of 14 vs 17 
seconds).

> 
> No one denies that "gcc -O0" is faster than "gcc -O3" for individual 
> compiles, and that the percentage difference will vary and sometimes be 
> large.
> 
> But that's not the point.  People who do C development for a living, do 
> not measure the quality of their tools by the speed of compiling random 
> junk they found on the internet to see which compiler saves them half a 
> second.
> 
> Factors that are important for considering a compiler can include, in no 
> particular order and not all relevant to all developers :
> 
> * Does it support the target devices I need?
> * Does it support the languages and language standards I want?
> * Does it have the extensions I want to use?
> * How good are its error messages at leading me to problems in the code?
> * How good is its static checks and warnings?
> * How efficient are the results?
> * Is it compatible with the libraries and SDK's I want to use?
> * Is it commonly used by others - colleagues, customers, suppliers?
> * Is it supported by the suppliers of my microcontrollers, OS, etc.?
> * Can I easily run it on multiple machines?
> * Can I back it up and run it on systems in the future?
> * Can I get hold of specific old versions of the tools?  Can I 
> reasonably expect the tools to be available for a long time in the future?
> * What are the policies for bug reporting, and bug fixing in the toolchain?
> * How easy is it to examine the generated code?
> * Does it play well with my IDE, such as cross-navigating between 
> compiler messages and source code?
> * Does it have any restrictions in its use?
> * How good is the documentation?
> * Does it have enough flexibility to tune it to my needs and preferences 
> for source code checks and warnings?
> * Does it have enough flexibility to tune it to my code generation needs 
> and preferences?
> * Can I re-use the same tool for multiple projects?
> * Can I use the same source and the same tool (or same family) on my 
> targets and for simulation on PC's?
> * Is the tool mainstream and well-tested by users in practice?
> * Does the same tool, or family of tools, work for different targets?
> * Am I familiar with the tool, its idiosyncrasies, and its options?
> * Is it common enough that I can google for questions about it?
> * Does it generate the debugging information I need?  Does it play well 
> with my debugger?
> * Is the price within budget?  Does it have locks, dongles, or other 
> restrictions?  Is commercial support available if I need it?
> * Does it have run-time debugging tools such as sanitizers or optional 
> range checks?
> * Does it run on the host systems I want to use?
> * Does it have (or integrate with) other tools such as profilers or code 
> coverage tools?
> * What is the upgrade path and the expectation of future improvements in 
> new versions?
> * Are there any legal requirements or ramifications from using the tool?
> * Is it fast enough that it is not annoying to use with normal options 
> and common build automation tools, running on a host within reasonable 
> budget?
> 
> 
> Notice how important raw compiler speed is in the grand scheme of things?

Yes, gcc ticks all the boxes. Except the last. For me it would be like 
driving my car at walking pace all over town, even though most of my 
time would be spent at various stopping places.

You get around that minimising your visits, taking short-cuts, using 
multiple cars each driven by different people to parallelise all the tasks.

But the cheapest car on the market that can do 30mph would fix it more 
easily.

You obviously have a very different view of what a compiler is for.

For me it's just a black box where you put source code in at end, and 
get runnable code at the other, preferably instantly.

And in the case of C code, I don't want it to depend on specific 
compilers. I used to test my code on 6 C compilers, now I limit it to three.

I use gcc ONLY to get an extra boost in speed. Except sometimes I have 
to use it because some open source code only works with gcc.


> The importance of tools is how effective they are for your use as a 
> /developer/.  Seconds saved on compile time are totally irrelevant 
> compared to days, weeks, months saved by tools that help find or prevent 
> errors, or that let you write better or clearer code.

For better or clearer code, try a new language. For me the biggest 
problems of developing with C are the language itself. All the 
industrial scale tools in the world can't fix the language.


> 
> I use gcc - specifically toolchains built and released by ARM - because 
> that is the tool that I rate highest on these factors.  If there were a 
> similar featured clang toolchain I'd look closely at that too.  And over 
> the years I have used many toolchains for many targets, some costing 
> multiple $K for the license.
> 
> Of course everyone likes faster compiles, all other things being equal. 
> But the other things are /not/ equal when comparing real-world 
> development tools with the likes of tcc or your little compiler.  The 
> idea that anyone should reasonably expect to get paid for wasting 
> customer time and money with those is just laughable.

That's a good point. How much money has been wasted in paying 
programmers by the hour to twiddle their thumbs while waiting for a rebuild?

========== REMAINDER OF ARTICLE TRUNCATED ==========