On flattening address spaces: the road not taken here is to run everything in something akin to the JVM, CLR, or WASM. Do that stuff in software not hardware.
You could also do things like having the JIT optimize the entire running system dynamically like one program, eliminating syscall and context switch overhead not to mention most MMU overhead.
Would it be faster? Maybe. The JIT would have to generate its own safety and bounds checking stuff. I’m sure some work loads would benefit a lot and others not so much.
What it would do is allow CPUs to be simpler, potentially resulting in cheaper lower power chips or more cores on a die with the same transistor budget. It would also make portability trivial. Port the core kernel and JIT and software doesn’t care.
> On flattening address spaces: the road not taken here is to run everything in something akin to the JVM, CLR, or WASM.
GPU drivers take SPIR-V code (either "kernels" for OpenCL/SYCL drivers, or "shaders" for Vulkan Compute) which is not that different at least in principle. There is also a LLVM-based soft-implementation that will just compile your SPIR-V code to run directly on the CPU.
What the ever loving hell, it was a perfectly reasonable idea in response to another idea.
They weren't saying it should be done, and went out of the way to make it explicit that they are not claiming it would be better.
It was a thought exploration, and a valid one, even if it would not pan out if carried all the way to execution at scale. Yes it was handwaving. So what? All ideas start as mere thoughts, and it is useful, productive, and interesting to trade them back and forth in these things called conversations. Even "fantasy" and "handwavy" ones. Hell especially those. It's an early stage in the pollination and generation of new ideas that later become real engineering. Or not, either way the conversation and thought was entertaining. It's a thing humans do, in case you never met any or aren't one yourself.
The brainstorming was a hell of a lot more valid, interesting, and valuable than this shit. "Just go away" indeed.
Have people really never used a higher level execution environment?
The JVM and the CLR are the most popular ones. Have people never looked at their internals? Then there's the LISP machines, Erlang, Smalltalk, etc., not to mention a lot of research work on abstract machines that just don't have the problems you get with direct access to pointers and hardware.
Some folks in the graphics programming community are allergic to these kind of modern ideas.
They are now putting up with JITs in GPGPUs, thanks to the market pressure from folks using languages like Julia and Python, that rather keep using those languages than having to rewrite their algorithms in C or C++.
These are communities that even adopting C over Assembly, and C++ over C, has been an uphill battle, let alone something like a JIT, that is like calling for the pitchforks and torches.
By the way, one of the key languages used in the Connection Machine mentioned on the article was StarLisp.
I'm going to call this out. The entire post obviously has bucket loads if aggression which can be taken as just communication style, but the last line was just uncalled for.
I have seen you make high quality responses to crazy posts.
You could also do things like having the JIT optimize the entire running system dynamically like one program, eliminating syscall and context switch overhead not to mention most MMU overhead.
Would it be faster? Maybe. The JIT would have to generate its own safety and bounds checking stuff. I’m sure some work loads would benefit a lot and others not so much.
What it would do is allow CPUs to be simpler, potentially resulting in cheaper lower power chips or more cores on a die with the same transistor budget. It would also make portability trivial. Port the core kernel and JIT and software doesn’t care.