Re: Baby X is bor nagain

On 18/06/2024 20:22, bart wrote:

On 17/06/2024 14:43, David Brown wrote:

On 17/06/2024 12:30, bart wrote:

On 17/06/2024 07:22, James Kuyper wrote:

On 6/13/24 10:43, Michael S wrote:

On Thu, 13 Jun 2024 13:53:54 +0200
David Brown <david.brown@hesbynett.no> wrote:

...

I know more than most C programmers about how certain C compilers
work, and what works well with them, and what is relevant for them -
though I certainly don't claim to know everything. Obviously Bart
knows vastly more about how /his/ compiler works. He also tends to
do testing with several small and odd C compilers, which can give
interesting results even though they are of little practical
relevance for real-world C development work.
>

>
Since he do compilers himself, he has much better feeling [that you
or me] of what is hard and what is easy, what is small and what is big,
what is fast and what is slow. That applies to all compilers except
those that are very unusual. "Major" compiler are not unusual at all.

>
The problem is that Bart's compiler is VERY unusual. It's customized for
his use, and he has lots of quirks in the way he thinks compilers should
work, which are very different from those of most other programmers.

>
>

In
particular, compilation speed is very important to him, while execution
speed is almost completely unimportant, which is pretty much the
opposite of the way most programmers prioritize those things.

>
Compilation speed is important to everyone. That's why so many tricks are used to get around the lack of speed in a big compiler, or so many extra resources are thrown at the problem.

>
What "tricks" ?

 Going to considerable lengths to avoid actually doing any compilation, or to somehow cache previous results (I mean things like .pch files rather than .o files).
 Have a look at any makefile.

As I suspected, your idea of "tricks" is mostly what other people call useful or essential tools.
I would use makefiles even if compilation was instant.  I /do/ use makefiles even when compilation is near instant.  I use them even if every run requires a full rebuild of everything.  I use them for all kinds of tasks other than compiling C - I first started using them for cross-assembly builds on DOS.
The point of a makefile (or other build system) is twofold:
1. Get consistent results, with minimal risk of sometimes getting the build process wrong.
2. Save time and effort for the developer.
It takes a special kind of dedication and stubborn, wilful ignorance to fail to see the benefit of build tools.  (make is not the only option available.)

 If compilation was instant, half the reasons for a makefile and its dependency graphs would disappear.

My makefiles would be simpler if compilation were instant, but they would be equally essential to my work.

 For the scale of programs I write, with the tools I use, compilation *is* more or less instant.

Some of us write serious code, use serious tools, and use them in serious ways.

 (Roughly 0.1 seconds; faster than it takes to press and release the Enter key, for my main compiler. My C compiler takes a bit longer, as it has been accelerated, but it tends to be used for smaller projects if it is something I've written.)
 

That depends on the language, type of code, and target platform. Typical C code on an x86_64 platform might be two or three times slower when using a poorly optimising compiler.  After all, the designers of x86 cpus put a great deal of effort into making shitty code run fast.

 Yes, that's one reason why you can get away without an optimiser, for sensibly written source code. But it also makes reasoning about optimal code much harder: removing superfluous instructions often makes code slower!
 

No, removing superfluous instructions very rarely makes code slower. But I agree that it is hard to figure out optimal code sequences on modern cpus, especially x86_64 devices, and even more so when you want fast results on a range of such processors.  Writing a good optimiser is a very difficult task.  But when compilers with good optimisers exist, /using/ them is not at all hard for getting reasonable results. (Squeezing out the last few percent /is/ hard.)