Not sure that this is practical currently, but it's surely theoretically possible if one of the titans of industry decided it was a good idea. Or if, say, Intel decided they wanted to create the next hit systems programming language.

See also https://queue.acm.org/detail.cfm?id=3212479 of course.

@Ivan Reese that's a nice article.. yes the machine that C targets its far from reality 🙂 But we can't actually target the real hardware anymore, as even the CPU ISA pretends its still 1990 or so

of all the things we can try to improve about this world, changing the hardware is about the furthest from our abilities 🙂 It may suck, but there's little point in complaining about it

the largest "whole systems" that I am somewhat familiar with are the ones at Google, and we're very far off any kind of optimizing at that level (in a compiler optimisation sense), it's all done by humans. This LLVM level optimization you so dislike controls 99% of data center costs

Also, even 50 years may not be enough to turn the tide in whatever way you think

remember, in the previous 50 years, we've seen little to no fundamental change in basic technologies like CPUs, memory, and OSes etc.. it is not impossible we're going to spend another 50 with them 😛

Also, even 50 years may not be enough to turn the tide in whatever way you think

Yes, yes. It may not turn at all or likely even turn a completely different way. But these ideas are still very interesting to me.

The levels to which a compiler like LLVM can collapse both code and data in C++ to almost nothing is crazy, nothing in the managed world compares.

"Managed" means uses a garbage collector, or compiles to VM code, or both. There's no necessary conflict between "managed" and using LLVM as a backend code generator, it's just a matter of designing the language or compiler to support this. My Curv language is an interpreted, dynamically typed language, with a subset that compiles into highly optimized machine code for the CPU and GPU.

@Ken Kan GPUs support data-parallel computing. This is a powerful paradigm for general purpose computing. If you have thousands, or tens of thousands of processing units for each gigabyte of memory, that might be a more scalable and efficient architecture, a better way to allocate your transistor budget. HP's "The Machine" project proposed to "bring processing closer to the data", and that's what GPUs do when you have thousands of cores and gigabytes of memory on the same chip. (Although the HP material doesn't talk about GPUs explicitly.) There have been many research projects that investigated scalable, massively parallel computing, with huge numbers of cores, each having local memory. The advantage of GPUs is that every personal computer has one (I'm including cell phones in my definition of personal computer). Currently, GPUs are difficult to program, the standard APIs are quite terrible. High level language support for data-parallel computing is quite limited. Conventional programming languages and libraries push you to use idioms that don't map well to data-parallel computing. So there are all these barriers that inhibit more widespread use of GPU capabilities, and I see a lot of wasted potential. Because of these barriers, GPUs are only used for a few specialized applications, like graphics and machine learning. If these barriers could be removed, via better languages and libraries, then GPUs and data-parallel programming might come to be used in a more general and pervasive way. GPU manufacturers will respond by designing GPU hardware to be more general purpose (eg, like the way they are currently responding to the rise of machine learning). That could eventually lead to more GPU-centric operating systems.