> Would a 60x faster compiler work for you?
Not if the resulting executable is, say, 10% slower. I could syntax check slightly faster, I suppose, but I already compile individual TUs for that. For testing, I need to test the actual build target. Also, the fastest comparison on http://bellard.org/tcc/ is a mere 9x faster on a real project. I wonder if they're doing better than 30% faster than GCC on the linux kernel since their 2004 numbers.
Also missing: C++ support. I no longer need PPC, fortunately.
And keep in mind: Despite kvetching about build performance, I make it even worse by running static analysis now and then, because that stuff is actually important to me.
> And it hasn't been a priority because in the past performance sins were always covered up by hardware getting faster (by itself, without any extra work). This is no longer the case, increases in single core performance are over.
Still getting wider, and still getting a little faster, but yes. I did get the memo about Moore's law "ending" a decade or so ago.
> Performance has also deteriorated in line with code bulk, [...]
Yes and no. Yes, more programs do more sloppy things that waste hardware performance now for little to no good reason (although I'll argue saving dev time can be worth it.) No, you cannot write a program that will efficiently unfold proteins on an Alto. No, you cannot make general purpose hardware that's as fast as a modern CPU or GPU with the Alto's fundamentally simpler design principles. No, you cannot efficiently and effectively use more complicated modern hardware with a similar line count as compilers and linkers for the Alto. No, really, the little computer in your hard drive really is playing a role in scheduling hardware operations to maximize your I/O throughput.
We're jumping through some really crazy complicated hoops in hardware to try and get more and more performance, and some of it requires hardware and software working in tandem. The minimum SLOC count to achieve our modern, expanded goals - even if you do something crazy like limit those goals to increased performance only - is absolutely rising for very reasonable reasons. Even if we assume most people 'waste' SLOC left and right, it doesn't follow that all codebases do, nor that all 'reasonable' codebases will be small enough to avoid problems.
Look, I get it, lean mean small programs kick some serious ass for a whole slew of reasons. I've sped up linking by a factor of 10x or so on some projects - on par with the 9x tcc factor above! - by switching from BFD to gold, with the latter focusing exclusively on elf binaries, instead of taking on BFD and all it's abstraction layers and non-elf target support. I imagine it's a much smaller program!
But I just told you the tradeoff: Specialization. I wasn't able to do this on all our target platforms, because not all of them even use elf. And, if it weren't for the fact that we were able to ditch BFD entirely, the total SLOC of our build toolchain would have, ironically, gone up from adding another linker into the mix as a result. Fortunately, I don't have to build our build toolchains - just any in-house ones. Our build configs did go up a few more LOC to override the defaults...
Unlike tcc, gold has not specialized itself to the point that it doesn't solve any of my problems, so it gets to join my toolset. I'm sure the reverse has happened to someone else. And plenty more deal with the situation where no specialized tool works for them. To ignore larger codebases requires you to ignore the generalized tools they fall back on.
> [...], and usually for no good reason whatsoever. There are a few good reasons, but they tend to be a small fraction of the whole problem.
An important distinction here: There's a lot of code that's absolutely useless, and has no good reason to exist... for solving your needs. This is very different from code that's absolutely useless, and has no good reason to exist. My pointless misfeature is someone else's core use case. And, it would seem, your pointless misfeature is perhaps my core use case.
And hey, that's cool. If tcc works for you, use it. But when people are using the multi-MLOC LLVM toolchain - it's not because software needs to get it's act together, but because it did get it's act together. I'm absolutely loving some of the tooling they're putting out, and wish I'd had it two decades ago.
And hey, perhaps current hardware performance sins (cough16GB max memory in 2016 for that pricecough) will be covered up by future software optimizations (by themselves, without any extra work on Apple's part) :). I imagine it'll involve more code though.