From: bc@freeuk.com
On 30/10/2025 18:59, Kaz Kylheku wrote:
> On 2025-10-30, bart wrote:
>> On 30/10/2025 15:04, David Brown wrote:
>>> On 30/10/2025 13:07, bart wrote:
>>
>>> You moan that compiles are too slow. Yet doing them in parallel is a
>>> "workaround". Avoiding compiling unnecessarily is a "workaround".
>>> Caching compilation work is a "workaround". Using a computer from this
>>> century is a "workaround". Using a decent OS is a "workaround". Is /
>>> everything/ that would reduce your scope for complaining loudly to the
>>> wrong people a workaround?
>>
>> Yes, they are all workarounds to cope with unreasonably slow compilers.
>
> The idea of incremental rebuilding goes back to a time when compilers
> were fast, but machines were slow.
What do you mean by incremental rebuilding? I usually talk about
/independent/ compilation.
Then incremental builds might be about deciding which modules to
recompile, except that that is so obvious, you didn't give it a name.
Compile the one file you've just edited. If it might impact on any
others (you work on a project for months, you will know it intimately),
then you just compile the lot.
>
> If you had /those/ exact compilers today, and used them for even a pretty
> large project, you could likely do a full rebuild every time.
>
> But incremental building didn't go away because we already had it,
> and we took that into account when maintaining compilers.
>
> Basically, decades ago, we accepted the idea that it can take several
> seconds to compile the average file, and that we have incremental
> building to help with that.
>
> And so, unsurprisingly, as machines got several orders of magnitude
> faster, people we have made compilers do more and become more bloated,
> so that it can still take seconds to do one file, and you use make to
> avoid doing it.
>
> A lot of is it the optimization. Disable optimization and GCC is
> something like 15X faster.
I don't think so. Not for C anyway, or that level of language. It's
usually about 3-5 times between -O0 and -O3, and even less between -O0
and -O2.
(The difference tends to greater for compiling bigger modules, but you
also get more global optimisations.)
> Optimization exhibits diminshing returns. It takes more and more
> work for less and less gain. It's really easy to make optimization
> take 10X longer for a fraction of a percent increase in speed.
>
> Yet, it tends to be done because of the reasoning that the program is
> compiled once, and then millions of instances of the program are run
> all over the world.
>
> One problem in optimization is that it is expensive to look for the
> conditions that enable a certain optimization. It is more expensive
> than doing the optimization, because the optimization is often
> a conceptually simple code transformation that can be done quickly,
> when the conditions are identified. But compiler has to look for those
> conditions everywhere, in every segment of code, every basic block.
> But it may turn out that there is a "hit" for those conditions in
> something like one file out of every hundred, or even more rarely.
>
> When there is no "hit" for the optimization's conditions, then it
> doesn't take place, and all that time spent looking for it is just
> making the compiler slower.
>
> The problem is that to get the best possible optimization, you have to
> look for numerous such rare conditions. When one of them doesn't "hit",
> one of the others might. The costs of these add up. Over time,
> compiler developers tend to add optimizatons much more than remove them.
>
>> They in fact all come across as excuses for your favorite compiler being
>> slow.
The problem is that there is no fast path for -O0:
c:\cx>tim gcc -O2 -s sql.c
Time: 39.685
c:\cx>tim gcc -O0 -s sql.c
Time: 7.819 **
That 8s vs 40s is welcome, but it can be also be:
c:\cx>tim bcc sql
Compiling sql.c to sql.exe
Time: 0.245
(** Note that this test uses windows.h, and gcc's version is much bigger
than mine, and accounts for 1.3s of that timing.)
So -O0 is still 25 slower than my product.
(Tcc would be even faster, but it's not working for this app ATM. I'm
sometimes considered whether gcc should just secretly bundle tcc.exe,
and run it for O-1.)
> Well, yes. Since we've had incremental rebuilding since the time VLSI
> machines were measured in single digit Mhz, we've taken it for granted
> that it will be used and so, to reiterate, that excuses the idea of
> a compiler taking several seconds to do one file.
>
>> Which one of these methods would you use to advertise the LPS throughput
>> of a compiler that you develop?
>
> It would be a lie to measure lines per second on anything but
> a single-core, complete rebuild of the benchmark program.
Exactly. But also, you really need to do comparisons with other products
on the same hardware, as LPS will be tied to the machine.
(My friend's ordinary laptop, used for ordinary consumer stuff, is 70%
faster than my PC. But I'm happy to give benchmark results on the PC.)
> High LPS compilers are somehow not winning in the programming
> marketplace, or at least some segments.
>
> That field is open!
>
> Once upon a time it seemed that GCC would remain unchallenged. Then
> Clang came along: but it too got huge, fat and slow within a bunch of
> years. This is mainly due to trying to have good optimizations.
It had to keep up with gcc. But it is not helped by being based around
LLVM which has grown into a monstrosity.
> You will never get a C compiler that has very high LSP throughput, but
> doesn't optimize as well as the "leading brand", to make inroads into
> the ecosystem dominated by the "leading brand".
People into compilers are obsessed with optimisation. It can be a
necessity for languages that generate lots of redundant code that needs
to be cleaned up, but not so much for C.
Typical differences of between -O0 and -O2 compiled code can be 2:1.
However even the most terrible native code will be a magnitude faster
than interpreted code.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
