Hacker News Reader

Comment by tinus_hn | Hacker News Reader

The obvious answer is to completely to the instructions the cpu uses internally. That would mean recompiling for every cpu revision though.

View on HN

That approach has (sort of) been tried before for superscalar architectures. VLIW architectures were the Next Big Thing in the early 1990s. The general idea is that the machine code explicitly told the CPU what to do with each of its execution units. It seems like a good idea. Intel released their i860 processor and waited for the cash to roll in.

The trouble was that because the machine code is pretty specific to the internal structure of the CPU every time they released a new major revision of the CPU the existing executables all had to be recompiled. All of their customers needed to get an entirely new OS, new third party software, they had to recompile all their own code, everything. This proved too much of a burden for many and popularity of the architecture suffered.

The other problem of these kinds of architectures is that they're quite inefficient at encoding code with lacks inherent parallelism. The instructions are long and most of them have to be NOPs if most of the execution units are idle - which is a lot of the time. This code bloat in turn wastes memory bandwidth and instruction cache space, making them overall not as efficient at using precious cache space as architectures with more compact instructions.

Kind of interesting to thing of the CPU as just another peripheral.

That was in the 90s though. We haven't had much "design" in CPU for 5 years. We are stuck with 4-5Ghz max, IPC seems to have its limit. And now we ran into security issues with too much clever hardware optimisation.

And it seems recompiling is relatively easy enough for servers? Where everything are in controlled environment?

> And now we ran into security issues with too much clever hardware optimisation.

I contest "now". It seems we ran into security issues at latest with Sandy Bridge (lazy FP) but many even earlier.

There have been some remarkable enhancements toward cache coherency and feeding data to large core counts while keeping latency from completely going crazy.

Those weren't the only problems with VLIW (and more specifically Itanium-type VLIW).

Recompiling and increased code size would've been fine if that were the only concerns.

The big problem is that so far, in general purpose workloads (the type with heavy control flow and gnarly memory access), VLIW was never able to match OoO in performance in terms of extracting enough ILP.

Yeah, it was "obvious" to Intel too when they made Itanium. And the rest is history.

> the "Itanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write

- Donald Knuth, source: http://www.informit.com/articles/article.aspx?p=1193856

No, because the CPU has information the compiler doesn't. The compiler throws away useful information while it compiles, yes, but the CPU gets new information at runtime which the compiler doesn't have.

Wasn't that the idea behind Transmeta - to JIT x86 operations in response to runtime feedback?

It was the idea behind HP Dynamo.

There's a good article here spoiled by the bitrotted formatting: http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.... It looks better if you use Firefox Reader view.

Nvidia's Project Denver also attempted something similar. It shipped in the form of the HTC Nexus 9, but it wasn't any faster than the competition in benchmarks (where you'd expect a JIT to shine). In the real world it's even worse because JITs are not good for responsiveness, particularly JITs that are not scheduled by the kernel and are unable to be scheduled behind important work. The CPU just randomly stopped running code to run a JIT instead.

But I was more just talking about things like branch predictors. You can be informed by runtime data without being a full on JIT, which is the world very nearly every modern CPU lives in these days.

I have a feeling where they were going with that was to push the internal data-flow representation to the CPU and have it figure out the register allocation, instruction selection and scheduling etc. right before execution.

Itanium 2.0?

It's not exactly clear what you mean by that comment, but this is almost the polar opposite of the Itanium approach, which was to push the low-level execution unit scheduling right up the stack to the compiler.

No, it wouldn't mean recompiling for every CPU revision.

Today's CPUs contains a kind of JIT compiler implemented in hardware. There is no reason why this JIT compiler couldn't be implemented in Software.

A lot of business-software runs already in some kind of VM, with a JIT compiler. This JIT compilers could easily spit out the hardware depended low-level code instead of e.g. x64 ASM. So a new hardware revision would only require an update to the runtime's JIT compiler.

I think IBM is doing something similar for decades now with their mainframes. "Native" executable are "only" some byte-code so you don't ever need to recompile your applications when you upgrade the hardware.

That introduces portability and cpu update issues. One of the reasons for high level languages and the trends in virtual machine/runtimes ( JVM, .Net ) is to decouple the hardware and the software to increase portability and stability and of course productivity. It's a tremendous logical gain in exchange for some physical performance loss. The trends have been clear for the past few decades. I don't the the pendulum swinging in the other direction any time soon.

Reply on news.ycombinator.com