On 24/06/2024 18:15, David Brown wrote:
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.
On my Windows machine, gcc -O0 took 0.20 seconds to build the 4-line hello.c. As measured with clock() when executing 'system("gcc hello.c")'.
On WSL using 'time', it took 0.146 seconds 'real' time, 0.007 seconds 'user' time, and 0.051 seconds 'sys' time.
I'm not sure what these mean, or which one, or which combination, you used to present your figures.
However, if someone is waiting for it to finish, it is the elapsed time that is relevant, since that is how long they have to wait!
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.
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?
Obviously /you/ don't care about fast build systems. It's perfectly alright for 90% of the time to build a project to be spent executing auto-conf scripts.
Some people also cared enough about linkers to develop a new generation of linker (maybe 'gold', maybe something even newer) that is supposed to be 5 times the speed of 'ld'.
Who told them that linking was a bottleneck? Obviously not you! (And not me either; linking is just a nuisance, but I hadn't noticed it being a drag on the stuff I did.)
>
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.
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're wrong. My 'car' would do the equivalent job of driving around town. Unless someone /wanted/ a vehicle that was more like a 40-tonne truck.
Let's go back a few weeks to when the topic was translating millions of lines like this:
unsigned char data[N] = {
1,
2,
....
};
This is not very demanding of a compiler; there is little static analysis to do, no advanced code generation, not even a way of minimising size: it has to occupy at least N bytes in the output.
So would you really demand gcc be used here, because an object file produced by any lesser compiler woudldn't be up to scratch? gcc will of course take 20 times longer to do the job. (And 200 times longer than my language takes to directly embed the original binary.)
Would you allow the use of a dedicated utility program which turns such text into a binary file? It would rather churlish to say yes to this, and no to the use of Tiny C which could probably do the job too.
How about assemblers, which aren't too challenging either; would you be snobbish and patronising about those too?
I see basic compilation, naively translating source code to native code, as an equally low level, mechanical task. It should always be available as something to fall back on.
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.
So cartoons like
https://xkcd.com/303/ have no basis in fact? It's just made up?
> You /do/ realise that the only person that "suffers" from slow gcc times
> is /you/ ?
Forums abound with horror stories. Here are quotes from just one thread:
------------------
Well a build used to take 6 or 7 minutes, and that's a long time for my little attention span. I'd always get distracted waiting for builds and waste even more time.
In short, if a developer is waiting on a build to run for one hour and doing nothing in that timeframe, the business is still spending $75 on average for that developer’s time—and potentially losing out on time that developer could be focusing on building more code.
I worked on a system where only linking the binary took 40-50 minutes. For some technical reasons there was no dynamic linking - only static - so you had to go through that delay for the slightest change.
This is why my computer and build server have an 11900k. Builds went from 45 minutes to 15.
This is the reason I stopped being a Java developer and embraced JS. Even the 1-3 minutes of build time was a big hit for me because it was just enough time for me to get distracted by something else and then the next thing you know, you have wasted 30 mins.
------------------
Maybe you should tell these guys how it's done!
That 1-3 minutes was the fastest build mentioned in these quotes, and that would absolutely kill me. Just 1-3 seconds feels like forever.
So what is taking the time? Is it very large programs? This is where I'd be interested in figures like MB of output per second.
If they're already doing 1-10MB/sec and it takes even one minute (so 60-600MB of output) then that's reasonable. The task is just huge, and they need to look at other approaches. But if they're only managing 10-100KB/sec, then those tools need attention.
The problem I have is that I've always worked in isolation and with my own tools. I never discovered fast or slow build processes were for anyone else. I just kept my own tools fast enough to suit me, even on 1980s hardware.
It turned out not only that they were very fast, but also toys!
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.
The wrong approach.
Baby X is bor nagain
Mac users (Was: Baby X is bor nagain)