4 ms·

I like that this architecture tackles a large problem in existing architectures, which Mike Pall put rather nicely: > All modern and advanced compilers convert

by PeCaN 8y ago

I like that this architecture tackles a large problem in existing architectures, which Mike Pall put rather nicely: > All modern and advanced compilers convert source code through various stages and representation into an internal data-flow representation, usually a variant of SSA. The compiler backend converts that back to an imperative representation, i.e. machine code. That entails many complicated transforms e.g. register allocation, instruction selection, instruction scheduling and so on. Lots of heuristics are used to tame their NP-complete nature. That implies missing some optimization opportunities, of course. > OTOH a modern CPU uses super-scalar and out-of-order execution. So the first thing it has to do, is to perform data-flow analysis on the machine code to turn that back into an (implicit) data-flow representation! Otherwise the CPU cannot analyze the dependencies between instructions. > Sounds wasteful? Oh, yes, it is. Mainly due to the impedance loss between the various stages, representations and abstractions. https://www.freelists.org/post/luajit/Ramblings-on-languages-and-architectures-was-Re-any-benefit-to-throwing-off-lua51-constraints https://www.freelists.org/post/luajit/Ramblings-on-languages...

tinus_hn 8y ago
The obvious answer is to completely to the instructions the cpu uses internally. That would mean recompiling for every cpu revision though.
- therein 8y ago
  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.
  - warkdarrior 8y ago
    Itanium 2.0?
    - caf 8y ago
      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.
- zokier 8y ago
  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 http://www.informit.com/articles/article.aspx?p=1193856
- kllrnohj 8y ago
  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.
  - petecox 8y ago
    Wasn't that the idea behind Transmeta - to JIT x86 operations in response to runtime feedback?
    - rwmj 8y ago
      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.html http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.... It looks better if you use Firefox Reader view.
    - kllrnohj 8y ago
      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.
- zik 8y ago
  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.
  - gm-conspiracy 8y ago
    Kind of interesting to thing of the CPU as just another peripheral.
  - ksec 8y ago
    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?
    - chx 8y ago
      > 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.
    - spamizbad 8y ago
- cityhomesteader 8y ago
  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.
- still_grokking 8y ago
  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.

by PeCaN 8y ago

tinus_hn 8y ago

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

therein 8y ago
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.
- warkdarrior 8y ago
  Itanium 2.0?
  - caf 8y ago
    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.
zokier 8y ago
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 http://www.informit.com/articles/article.aspx?p=1193856
kllrnohj 8y ago
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.
- petecox 8y ago
  Wasn't that the idea behind Transmeta - to JIT x86 operations in response to runtime feedback?
  - rwmj 8y ago
    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.html http://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-1.... It looks better if you use Firefox Reader view.
  - kllrnohj 8y ago
    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.
zik 8y ago
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.
- gm-conspiracy 8y ago
  Kind of interesting to thing of the CPU as just another peripheral.
- ksec 8y ago
  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?
  - chx 8y ago
    > 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.
  - spamizbad 8y ago
cityhomesteader 8y ago
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.
still_grokking 8y ago
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.