The Hardware Culture, or: What They Build, Works! Can We Say the Same?
Yossi Kreinin throws down the gauntlet to all those who believe that a CPU ought to be designed specifically around the needs of high-level languages:
Do you think high-level languages would run fast if the stock hardware weren’t “brain-damaged”/”built to run C”/”a von Neumann machine (instead of some other wonderful thing)”? You do think so? I have a challenge for you. I bet you’ll be interested….
My challenge is this. If you think that you know how hardware and/or compilers should be designed to support HLLs, why don’t you actually tell us about it, instead of briefly mentioning it?
In his excellent follow-up to the challenge, he argues – fairly convincingly in my opinion – that a move toward “high-level” CPUs would come at substantial cost, and lead to no miraculous speed-up of dynamically-typed code. However, I still believe that ultimately, today’s architectures ought to be consigned to the junk heap in favor of a resurrected multi-GHz Lisp Machine descendant. The best argument for this is hinted at in another one of Kreinin’s posts:
Hardware really does tend to be the product of a more… adult engineering culture than software. I don’t believe I’ve ever encountered a piece of computer hardware which was a steaming turd of sheer dysfunction (non-deterministic behavior, illogical/undocumented operation, simple defectiveness) in the same manner the average piece of software of any substantial complexity almost invariably is. On further contemplation, I can think of a handful of products which might qualify – yet in each case the fault lay in firmware – once again the foul excreta of software engineers.
Bridges are expected to stand up, and on the “first try,” even! Planes are expected to stay aloft. And yet programmers seem to be content with forever competing in the engineering version of the Special Olympics, where different, “special” standards apply and products are not expected to actually do what they say on the box – at any rate, the idea of offering a legal warranty of proper function (or even of not causing utter disaster, in the manner customary in every other industry) for a software product is seen as preposterous.
I see this as a convincing argument for “silicon big government.” Move garbage collection, type checking, persistence of storage, and anything else which is unambiguously necessary in a modern computing system into hardware – the way graphics processing has been moved. Forget any hypothetical efficiency boost: I favor such a change for no other reason than the fact that cementing such basic mechanisms in silicon would force people to get it right. On the first try – the way real engineers are expected to. Yes, get it right – or pay dearly.
I think a LispM could make a great desktop/server because it would *force* safety and security. I think that GC, type checking, etc. ultimately converge to correctness in software implementations VMs. I think the problem isn’t correctness as much as it is optionality. The big problem with today’s commodity hardware is that nothing prevents you from writing in C or C++.
On the other hand, not being a believer in big government – silicon or not – I tend to think along the lines of “if people prefer low cost and low security, so be it, even though I strongly disagree” (as opposed to something like “I wish they weren’t so stupid and made the right choice”, which eventually tends to imply “I wish someone made them behave properly”, which tends to imply non-silicon big governments.)
I claim that HLLs in fact have a cost overhead measured in operations per (second*mm^2), no matter where this cost is payed – hw or sw. From that point it’s a matter of choice, and I still prefer HLLs.