Re: else ladders practice

On 19/11/2024 16:11, Scott Lurndal wrote:

Bart <bc@freeuk.com> writes:

On 19/11/2024 01:53, Waldek Hebisch wrote:

 

More complicated does not mean slower.  Binary search or hash tables
are more complicated than linear search, but for larger data may
be much faster.

>
That's not the complexity I had in mind. The 100-200MB sizes of
LLVM-based compilers are not because they use hash-tables over linear
search.

 You still have this irrational obsession with the amount of disk
space consumed by a compiler suite - one that is useful to a massive
number of developers (esp. compared with the user-base of your
compiler).
 The amount of disk space consumed by a compilation suite is
a meaningless statistic.   10MByte disks are a relic of the
distant past.

Yes is. But what is NOT meaningless is everything else that goes with it: vast complexity, and slow compile times, and that's just for the apps you build with the tool. Building LLVM itself can be challenging.

 

My tools can generally build my apps from scratch in 0.1 seconds; big
compilers tend to take a lot longer. Only Tiny C is in that ballpark.

 And Tiny C is useless for the majority of real-world applications.
 How many people are using your compiler to build production applications?

It doesn't matter. It's enough to illustrate that routine compilation CAN be done at up to 100 times faster than those big tools and with a program that could fit on a floppy. Presumably at a significant power saving as well, as that seems to be a big thing these days.
If a simple implementation has trouble with big applications, then that would need to be looked at.
But I suspect the trouble doesn't lie within the small compiler. Probably those big compilers have had to be endlessly tweaked over decades to deal myriad small problems, perhaps bugs and corner cases within the C language, or need to compile legacy code that is too fragile to fix, all sorts of stuff.
Or, where the compilers were not specially modded, then codebases would have headers with conditional blocks that special-case particular compilers with tweaks to get around the idiosyncrasies of each.
Or, the apps depend on C extensions implemented only by a big compiler.
The end result is that when some upstart comes along with a new, streamlined compiler, it will not be able build that codebase.
But, try creating a NEW real-world application that is primarily developed and tested with Tiny C, then you will see two revelations:
* It *will* build with Tiny C with no problems, unsurprisingly
* It will also build with any of your big compilers because the code is necessarily conservative.
Congratulations, you now have a much healthier codebase that works cross-compiler without all those #ifdef blocks.