Re: Baby X is bor nagain

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?
Perhap just once you can forget about analysing every obscure corner of the code to quickly try out the latest change to see if it fixes that problem.
 > It's like being

hired to dig up a road and arriving with kid's sand spade then claiming it is better than a mechanical digger because it is smaller and lighter.

Have you considered that you could have a product that works like gcc, in ticking most of those boxes, and yet could be nearly as fast as TCC?
But nobody is interested in that; customers such as you are so inured to slow build-times, and have learnt to get around its sluggishness (and in your case even convinced yourself that it is really quite fast), so that there simply aren't enough people complaining about it.