7 ms·

My takeaway from this presentation: - To achieve instruction-level parallelism, traditional architectures (his example: Haswell) often employ very messy techni

My takeaway from this presentation: - To achieve instruction-level parallelism, traditional architectures (his example: Haswell) often employ very messy techniques like register renaming which create a huge amount of complexity increasing power-consumption. - He has focused on one such technique called Very Long instruction word (VLIW), and has taken it to an extreme: the technique he proposes is to throw away general purpose registers, and replace it with a "belt": a write-once linear tape of memory (implemented using stacks). - He then points out various advantages of this model, including in-order execution (ILP traditionally requires reordering), short pipeline, and overall simplification of architectures. All this looks fine on paper, but I don't see a proposed instruction set, or any indication of what realization of this model will require. In short, it's a cute theoretical exercise. So, let's look at what the unworkable problems with Haswell are, and what's being done to fix them. Yes, nobody can seem to be able to figure out how to reduce power consumption on performant x86 microarchitectures beyond a point. It's a very old architecture, and I'm hopeful about the rise of ARM. The solution is not to throw away general purpose registers, but rather to cut register renaming and make ILP easier to implement by using a weak memory model (which is exactly what ARM does). ARM64 is emerging and the successes of x86 are slowly percolating to it [1]. Moreover, the arch/arm64 tree in linux.git is 1.5 years old and is under active development; we even got virt/kvm/arm merged in recently (3 months ago), although I'm not sure how it works without processor extensions (it's not pure pvops). ARM32 already rules embedded and mobile devices, and manufacturers are interested in taking it to heavy computing. In short, the roadmap is quite clear: ARM64 is the future. The core of the Linux memory barriers model described in Documentation/memory-barriers.txt [2] (heavily inspired by the relaxed DEC Alpha) should tell you what you need to know about why a weak memory model is desirable. [1]: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf http://www.arm.com/files/downloads/ARMv8_Architecture.pdf [2]: https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt https://github.com/torvalds/linux/blob/master/Documentation/...

Scaevolus 13y ago
A weak memory model has almost nothing to do with ILP. To exploit ILP, ARM has to do the same thing as every other register architecture: move to a superscalar out-of-order architecture. There's no real alternative. The weak memory model makes cache coherency protocols simpler/faster, but won't save you from false register dependencies. Three-address code might make it possible to defer the costs of complex register renaming, but ARM has discovered the importance of code density, and Thumb-2 (2-address code) is preferred for most functions.
- artagnon 13y ago
  I see. Can you explain to me how it fixes the power consumption problem? Yes, I know that it needs to reorder instructions to achieve ILP, but isn't that the entire point of a weak architecture? To reduce the memory barriers and weaken the ordering constraints, making it easier to reorder? What are false register dependencies? And how does a three-address code help in register renaming? Some reading references would help. I'm currently reading [1]. [1]: http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2...
  - thedigitalengel 13y ago
    A "false" register dependency is a Write-after-read (WAR) [1]. As far as three address code making register renaming easier, I'm not sure what the author had in mind -- isn't `add $5, %rax` essentially a condensed form of `add $5, %rax, %rax` (which is a 3AC)? In fact, 3AC is _more_ general and should make register renaming harder if anything at all. [1] http://en.wikipedia.org/wiki/Register_renaming http://en.wikipedia.org/wiki/Register_renaming
    - Scaevolus 13y ago
      A careful compiler could avoid WARs more easily in 3AC than 2AC (by spacing reuse of registers), so an architecture without renaming could still extract ILP. It's not a general or optimal solution, though.
  - solarexplorer 13y ago
    The ordering constraints of memory models are foremost between instructions that are executed on different processors. As long as instructions execute on a single processor, everything appears to execute sequentially (even if it doesn't). The real cost of weak memory models is in software. Programmers that write multithreaded code need to understand the memory models. And few actually do, because these things are not trivial. So you gain a few percent of performance with a weak memory model and at the same time you dramatically restrict the number of programmers who can write correct code. A very bad deal. Hennessy, Patterson: "Computer Architecture, A Quantitative Approach." is the standard introduction to computer architecture.
igodard 13y ago
The Mill is strong sequentially consistent throughout. There are no membar operations, and the Linux macroes for that purpose are empty. This design choice had two motivations: 1) membar is fabulously expensive; and 2) weaker consistency models are incomprehensible to mere mortals.

Scaevolus 13y ago

A weak memory model has almost nothing to do with ILP. To exploit ILP, ARM has to do the same thing as every other register architecture: move to a superscalar out-of-order architecture. There's no real alternative. The weak memory model makes cache coherency protocols simpler/faster, but won't save you from false register dependencies. Three-address code might make it possible to defer the costs of complex register renaming, but ARM has discovered the importance of code density, and Thumb-2 (2-address code) is preferred for most functions.

artagnon 13y ago
I see. Can you explain to me how it fixes the power consumption problem? Yes, I know that it needs to reorder instructions to achieve ILP, but isn't that the entire point of a weak architecture? To reduce the memory barriers and weaken the ordering constraints, making it easier to reorder? What are false register dependencies? And how does a three-address code help in register renaming? Some reading references would help. I'm currently reading [1]. [1]: http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.07.23a.pdf http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2...
- thedigitalengel 13y ago
  A "false" register dependency is a Write-after-read (WAR) [1]. As far as three address code making register renaming easier, I'm not sure what the author had in mind -- isn't `add $5, %rax` essentially a condensed form of `add $5, %rax, %rax` (which is a 3AC)? In fact, 3AC is _more_ general and should make register renaming harder if anything at all. [1] http://en.wikipedia.org/wiki/Register_renaming http://en.wikipedia.org/wiki/Register_renaming
  - Scaevolus 13y ago
    A careful compiler could avoid WARs more easily in 3AC than 2AC (by spacing reuse of registers), so an architecture without renaming could still extract ILP. It's not a general or optimal solution, though.
- solarexplorer 13y ago
  The ordering constraints of memory models are foremost between instructions that are executed on different processors. As long as instructions execute on a single processor, everything appears to execute sequentially (even if it doesn't). The real cost of weak memory models is in software. Programmers that write multithreaded code need to understand the memory models. And few actually do, because these things are not trivial. So you gain a few percent of performance with a weak memory model and at the same time you dramatically restrict the number of programmers who can write correct code. A very bad deal. Hennessy, Patterson: "Computer Architecture, A Quantitative Approach." is the standard introduction to computer architecture.

igodard 13y ago

The Mill is strong sequentially consistent throughout. There are no membar operations, and the Linux macroes for that purpose are empty. This design choice had two motivations: 1) membar is fabulously expensive; and 2) weaker consistency models are incomprehensible to mere mortals.