Re: Baby X is bor nagain

On 24/06/2024 18:19, bart wrote:

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.

And the relevance of that is... what?  Absolutely nothing.  We've already established that for some files, the difference is below the measurement threshold and for some (such as Scott's C++ example) it is massive.
But just to please you, and not because it has any bearing on reality, I isolated a couple of C files from my code, removed the stuff that is specific to the target, and compiled with native gcc -O0 and -O2.
For one file (the largest C file in the project), "gcc -O0" took 0.085 seconds.  "gcc -O2" took 0.134 seconds.  Yes, optimising was slow - but the time was negligible.  For the other file, both compiles were 0.025 seconds - too fast to be distinguishable from noise.
What have we learned from this experiment?  We have learned SFA about compilation speed - the only thing you, perhaps, have learned is that I know what I am talking about when I say such measurements are pointless.

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.
 

If they learn that it is not worth fussing about compilation speed and they should use the options that give the results they want - optimisation, warnings, etc., as desired - then they have learned something useful.  If they think they have learned about any particular percentage figure, then they have misunderstood.

>

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?

Why do you think that is an appropriate way to guess the size of the project?  Michael does embedded development - that's likely to be a pretty big project with a lot of files.  This is not PC compilation where a "Hello, world" file can reach that size if statically linked.

 

>

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 cares about your figures.  No one, except you, cares about /my/ figures.  Sometimes people care about the build speed of /their/ code, using /their/ choice of compiler and /their/ choice of options on /their/ computers.  Do you /really/ not understand that the timings you get are utterly pointless to everyone else?

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

No, it does not tick all the boxes.  The toolchains I use tick most of them (including all the ones that I see as hard requirements), and do better than any alternatives, but they are not perfect.  They do, however, happily pass the last one.  I have yet to find a C compiler that was not fast enough for my needs.

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 still don't understand.  You are telling people how fantastically fast your car is, without realising it is just a remote-controlled toy car.  Nobody cars if your toy runs faster than a real tool - people will still choose the real tool.  And the real tools run fast enough for real developers doing real work.

 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.

Yes.

 

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 often work with C++ rather than C.  But I know without any doubt at all, that I write better and clearer C code than you do.  C is far from a "perfect" language, but it is a lot better if you don't cripple it with determined ignorance, absurd self-imposed limitations and crappy tools.

 

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

None that I know of.  Your worries about compiler speed are imaginary or self-imposed.

 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?
 

Yes.  There are two issues with that.  First, a compiler as fast as tcc would make no practical difference at all to my development process. gcc is more than fast enough for my needs.  Secondly, there is no such tool, never has been, and I can confidently say, never will be.  I want far more from my tools than tcc can offer, and that takes more time.
If gcc was ten times slower than it is, it might get annoying sometimes, and I'd then get a faster computer.

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.
 

You /do/ realise that the only person that "suffers" from slow gcc times is /you/ ?