3 ms·

His terminology might be a tiny bit off, but I think it's actually pretty close. Intel's optimization manual (https://software.intel.com/sites/default/files/man

by nkurz 9y ago

His terminology might be a tiny bit off, but I think it's actually pretty close. Intel's optimization manual (https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf https://software.intel.com/sites/default/files/managed/9e/bc...) in 2.4.2.6 says "Micro-fusion fuses multiple micro-ops from the same instruction into a single complex micro-op. The complex micro-op is dispatched in the out-of-order execution core." So while the title probably might have been better as "Micro-fusion of µops", "Micro-op fusion" isn't particularly far afield. It's called "micro-fusion", by the way, because the µops are fused together from the point of view of parts of the processor, but then "unlaminated" to be executed. The alternative is "macro-fusion", where certain instruction pairs (cmp-jcc) are fused by the decoder and treated as one after that. Using Intel's terms, RMW-type instructions are indeed always handled internally using micro-fusion.

deleted 9y ago
[deleted]
BeeOnRope 9y ago
Careful with the word "unlamination", since it is usually referring to a different thing than the usual splitting up of micro-fused ops at execution. As far as micro-fusion, there are at at least three interesting possibilities for the uops originating from the same instruction (with a memory operand): 1) No micro-fusion at all, e.g., for shrx and friends. The number of fused domain and unfused domain uops is the same. 2) Fusion in the uop cache (and probably the IDQ), but not the RAT and later stages. This is a case where the instructions are fused at decode, but are "unlaminated" before rename, and hence it usually has similar performance to no fusion at all (but it does save space in the uop cache), since RAT is more likely to be a performance limitation. If you look at the performance counters to determine fusion, this will look like case (1) (unless you check the DSB uops delivered one, I guess). 3) Full micro-fusion. This is the "normal" micro-fusion that people usually talk about: fusion persists through the RAT and get split up for execution. As far as I know, "unlamination" refers to the process that distinguishes between type (2) and type (3) - the former are unlaminated and the latter aren't. The existence of type (2) isn't even really clear from the classic sources like Agner's doc, and the behavior has changed even on recent archs (e.g., Skylake unlaminates less scnearios than Haswell). All the gory details are here: https://stackoverflow.com/q/26046634/149138 https://stackoverflow.com/q/26046634/149138 About RMW ops, it usually ends up as 4 unfused uops (store data, store AGU, load, ALU) which get fused into two micro-fused pairs (the store, and the load-ALU) op, not fully fused into one uop. The same concerns about type (2) vs type (3) likely apply also, although I haven't tested it.
- nkurz 9y ago
  Thanks, I now realize I hadn't been distinguishing 2 from 3. I'm still unsure about when unlamination occurs, but I'll be more careful with the term until I do. Regarding RMW ops, I agree, but was sticking with the parent's terminology. I'd normally refer to them as "load-ops" or "op-stores".
  - BeeOnRope 9y ago
    Well the link above pretty much covers comprehensively when unlamination occurs, and I haven't found any discrepancies with the info there yet. In fact, I noticed that it even covers the RMW op case: indeed they still suffer unlamination of 1 of their two fused uops (probably the load/op pair since complex stores aren't unlaminated anymore on Haswell+). About RMW I wasn't trying to make any point about terminology - just mentioning pointing out that they are special in that they may micro-fuse twice (although it turns out that I was wrong and inc can't do it - but add can), unlike load-op which micro-fuse at most once. So as it turns out, there is zero extra micro-fusion going on in the "fused" vs "unfused" examples, because of the limitation wrt inc. There is still micro-fusion of the store part, but both examples get that equally. The implication is that compilers are probably better off using "add [mem], 1" in some cases over inc, since it fuses better. It wouldn't actually fuse better in this case though due to the unlamination - but if you could simplify the addressing mode it would. I wrote a reply on the blog laying this out in more detail but unfortunately Disqus "detected it as spam".

by nkurz 9y ago

deleted 9y ago

[deleted]

BeeOnRope 9y ago

Careful with the word "unlamination", since it is usually referring to a different thing than the usual splitting up of micro-fused ops at execution. As far as micro-fusion, there are at at least three interesting possibilities for the uops originating from the same instruction (with a memory operand): 1) No micro-fusion at all, e.g., for shrx and friends. The number of fused domain and unfused domain uops is the same. 2) Fusion in the uop cache (and probably the IDQ), but not the RAT and later stages. This is a case where the instructions are fused at decode, but are "unlaminated" before rename, and hence it usually has similar performance to no fusion at all (but it does save space in the uop cache), since RAT is more likely to be a performance limitation. If you look at the performance counters to determine fusion, this will look like case (1) (unless you check the DSB uops delivered one, I guess). 3) Full micro-fusion. This is the "normal" micro-fusion that people usually talk about: fusion persists through the RAT and get split up for execution. As far as I know, "unlamination" refers to the process that distinguishes between type (2) and type (3) - the former are unlaminated and the latter aren't. The existence of type (2) isn't even really clear from the classic sources like Agner's doc, and the behavior has changed even on recent archs (e.g., Skylake unlaminates less scnearios than Haswell). All the gory details are here: https://stackoverflow.com/q/26046634/149138 https://stackoverflow.com/q/26046634/149138 About RMW ops, it usually ends up as 4 unfused uops (store data, store AGU, load, ALU) which get fused into two micro-fused pairs (the store, and the load-ALU) op, not fully fused into one uop. The same concerns about type (2) vs type (3) likely apply also, although I haven't tested it.

nkurz 9y ago
Thanks, I now realize I hadn't been distinguishing 2 from 3. I'm still unsure about when unlamination occurs, but I'll be more careful with the term until I do. Regarding RMW ops, I agree, but was sticking with the parent's terminology. I'd normally refer to them as "load-ops" or "op-stores".
- BeeOnRope 9y ago
  Well the link above pretty much covers comprehensively when unlamination occurs, and I haven't found any discrepancies with the info there yet. In fact, I noticed that it even covers the RMW op case: indeed they still suffer unlamination of 1 of their two fused uops (probably the load/op pair since complex stores aren't unlaminated anymore on Haswell+). About RMW I wasn't trying to make any point about terminology - just mentioning pointing out that they are special in that they may micro-fuse twice (although it turns out that I was wrong and inc can't do it - but add can), unlike load-op which micro-fuse at most once. So as it turns out, there is zero extra micro-fusion going on in the "fused" vs "unfused" examples, because of the limitation wrt inc. There is still micro-fusion of the store part, but both examples get that equally. The implication is that compilers are probably better off using "add [mem], 1" in some cases over inc, since it fuses better. It wouldn't actually fuse better in this case though due to the unlamination - but if you could simplify the addressing mode it would. I wrote a reply on the blog laying this out in more detail but unfortunately Disqus "detected it as spam".