5 ms·

Talk is cheap. The TL;DW is that the mill cpu will have better performance than existing CPUs without speculative execution because it has "deferred loads," wh

by twtw 8y ago

Talk is cheap. The TL;DW is that the mill cpu will have better performance than existing CPUs without speculative execution because it has "deferred loads," while the straw man not-mill architecture doesn't and therefore stalls after every load. Also, newsflash - Spectre doesn't impact architectures that don't speculate. This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load," and require less work from the compiler. If you have independent instructions following a load, any existing architecture worth its salt will notice that and execute them while the load is in progress. It's potentially a neat idea to include the number of cycles until load retire in the instruction, but it's a joke to pretend that it's higher performance than what x86 does and will get you back all the performance lost by not speculating. I can't help but think that the mill architecture gets a lot of hype from a lot of people that don't know very much about computer architecture. There have been lots of great ideas that didn't pan out for general purpose computing, and I'm not sure that this vaporware architecture deserves to be thought about.

snuxoll 8y ago
> This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load" [...] Except existing CPU's spend a lot of die space and power budget on doing speculative execution to hide the stall, the point of a deferred load is you don't need all this hardware to extract the same performance. > and require less work from the compiler. [...] Three words: static single assignment. If you can work out the dataflow of a function you already have everything you need to order loads in the most efficient way possible, this is why all of Mill Computing's work has been around LLVM because LLVM IR forces SSA by design. Hell, your compiler doesn't even need to think about the ordering if it relies on LLVM to do the native code generation, because the Mill backend is supposed to do all of this for you. > It's potentially a neat idea to include the number of cycles until load retire in the instruction, but it's a joke to pretend that it's higher performance than what x86 does and will get you back all the performance lost by not speculating. Deferred loads alone aren't there to beat x86 in terms of performance, they're there to avoid needing all the costly out-of-order hardware while avoiding memory stalls that previous statically scheduled/in-order machines incur. There's other features in the architecture to bring better performance, but that's all around the VLIW-like design.
- gpderetta 8y ago
  As far as I know (and I don't know much because I'm not a compiler guy) LLVM (and most compilers) doesn't keep everything in SSA form. Any value whole address has escaped (most of the things not in the C stack and evem some local variables as well) must treated as memory. I think that not automatic, not recently used variables would also be the values that would benefit the most from deferred loads. So IIRC Mill has hardware to help with aliasing but it wouldn't in fact plug out of the box in LLVM. Do the Mill guys even have an LLVM backend yet? Or even any compiler at all?
  - Veedrac 8y ago
    I believe the latest we've heard is that their LLVM backend is mostly working but still pretty buggy.
- jcranmer 8y ago
  > Three words: static single assignment. If you can work out the dataflow of a function you already have everything you need to order loads in the most efficient way possible The ordering of loads has almost nothing to do with dataflow (with the slight caveat that data dependencies from loads guarantees a small amount of the memory order). I'm speaking from experience here, any computation DAG model is going to very quickly run into the problems of dealing with branches and the inherently undecidable problem of static alias analysis.
deepnotderp 8y ago
> This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load," and require less work from the compiler. If you have independent instructions following a load, any existing architecture worth its salt will notice that and execute them while the load is in progress. <Citation needed>. BTW, deferred loads were rediscovered as "decoupled load" (http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf) and achieved a respectable 8.4% avg speedup. > It's potentially a neat idea to include the number of cycles until load retire in the instruction, but it's a joke to pretend that it's higher performance than what x86 does and will get you back all the performance lost by not speculating. That's not at all what's claimed. The entire idea is that you try to approximate OoO performance, not beat OoO performance. > I can't help but think that the mill architecture gets a lot of hype from a lot of people that don't know very much about computer architecture. There have been lots of great ideas that didn't pan out for general purpose computing, and I'm not sure that this vaporware architecture deserves to be thought about. I mean, it's been discussed as a valid idea by people on the P6 team (one of the first commercial OoOs), but what would they know? ¯\_(ツ)_/¯
- twtw 8y ago
  "<Citation needed>" This is a joke, right? Or are you actually calling me out for no evidence on a discussion of the mill architecture, which has been proclaimed for a decade as the greatest thing since sliced bread without a shred of supporting evidence?
  - deepnotderp 8y ago
    You claimed that deferred loads help less than prefetching and scoreboarding. You should substantiate that claim. In any case, see the linked paper for why you're probably wrong on that point.
petermcneeley 8y ago
"I can't help but think that the mill architecture gets a lot of hype from a lot of people that don't know very much about computer architecture. There have been lots of great ideas that didn't pan out for general purpose computing, and I'm not sure that this vaporware architecture deserves to be thought about." This architecture is basically itanium++ which was a very serious arch but didnt make it (just like PS3 Cell). To ask if this arch has any possible future one should really ask why itanium didnt succeed.

by twtw 8y ago

snuxoll 8y ago

> This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load" [...] Except existing CPU's spend a lot of die space and power budget on doing speculative execution to hide the stall, the point of a deferred load is you don't need all this hardware to extract the same performance. > and require less work from the compiler. [...] Three words: static single assignment. If you can work out the dataflow of a function you already have everything you need to order loads in the most efficient way possible, this is why all of Mill Computing's work has been around LLVM because LLVM IR forces SSA by design. Hell, your compiler doesn't even need to think about the ordering if it relies on LLVM to do the native code generation, because the Mill backend is supposed to do all of this for you. > It's potentially a neat idea to include the number of cycles until load retire in the instruction, but it's a joke to pretend that it's higher performance than what x86 does and will get you back all the performance lost by not speculating. Deferred loads alone aren't there to beat x86 in terms of performance, they're there to avoid needing all the costly out-of-order hardware while avoiding memory stalls that previous statically scheduled/in-order machines incur. There's other features in the architecture to bring better performance, but that's all around the VLIW-like design.

gpderetta 8y ago
As far as I know (and I don't know much because I'm not a compiler guy) LLVM (and most compilers) doesn't keep everything in SSA form. Any value whole address has escaped (most of the things not in the C stack and evem some local variables as well) must treated as memory. I think that not automatic, not recently used variables would also be the values that would benefit the most from deferred loads. So IIRC Mill has hardware to help with aliasing but it wouldn't in fact plug out of the box in LLVM. Do the Mill guys even have an LLVM backend yet? Or even any compiler at all?
- Veedrac 8y ago
  I believe the latest we've heard is that their LLVM backend is mostly working but still pretty buggy.
jcranmer 8y ago
> Three words: static single assignment. If you can work out the dataflow of a function you already have everything you need to order loads in the most efficient way possible The ordering of loads has almost nothing to do with dataflow (with the slight caveat that data dependencies from loads guarantees a small amount of the memory order). I'm speaking from experience here, any computation DAG model is going to very quickly run into the problems of dealing with branches and the inherently undecidable problem of static alias analysis.

deepnotderp 8y ago

> This is great, except for that existing CPUs don't stall after issuing a load. Scoreboarding + prefetch are together capable of more than this "deferred load," and require less work from the compiler. If you have independent instructions following a load, any existing architecture worth its salt will notice that and execute them while the load is in progress. <Citation needed>. BTW, deferred loads were rediscovered as "decoupled load" (http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf http://people.duke.edu/~bcl15/documents/huang2016-nisc.pdf) and achieved a respectable 8.4% avg speedup. > It's potentially a neat idea to include the number of cycles until load retire in the instruction, but it's a joke to pretend that it's higher performance than what x86 does and will get you back all the performance lost by not speculating. That's not at all what's claimed. The entire idea is that you try to approximate OoO performance, not beat OoO performance. > I can't help but think that the mill architecture gets a lot of hype from a lot of people that don't know very much about computer architecture. There have been lots of great ideas that didn't pan out for general purpose computing, and I'm not sure that this vaporware architecture deserves to be thought about. I mean, it's been discussed as a valid idea by people on the P6 team (one of the first commercial OoOs), but what would they know? ¯\_(ツ)_/¯

twtw 8y ago
"<Citation needed>" This is a joke, right? Or are you actually calling me out for no evidence on a discussion of the mill architecture, which has been proclaimed for a decade as the greatest thing since sliced bread without a shred of supporting evidence?
- deepnotderp 8y ago
  You claimed that deferred loads help less than prefetching and scoreboarding. You should substantiate that claim. In any case, see the linked paper for why you're probably wrong on that point.

petermcneeley 8y ago

"I can't help but think that the mill architecture gets a lot of hype from a lot of people that don't know very much about computer architecture. There have been lots of great ideas that didn't pan out for general purpose computing, and I'm not sure that this vaporware architecture deserves to be thought about." This architecture is basically itanium++ which was a very serious arch but didnt make it (just like PS3 Cell). To ask if this arch has any possible future one should really ask why itanium didnt succeed.