Intel i7 loop performance anomaly (2013)

Re:Intel i7 loop performance anomaly (2013) by nkurz on Saturday December 16, 2017 @01:30PM (#15940933)

No, the legacy decoder is virtually unused. This loop was designed to take advantage of the rules of the DSB.

OK, think I see now. The DSB path is only able to inject one "way" per cycle, and through NOP padding you are able to ensure that each "way" only contains a single instruction? While I can find clear descriptions of what can fit in a "way", I haven't found a clear statement of the "one way per cycle" restriction, although it would explain observed behavior.

Practically, it seems like the effect would be the same if one "defeated" the DSB and came up with a similar strategy for causing the legacy MITE to trickle in instructions. The overall goal is to restrict speculative execution of loads and stores in cases where one knows that the speculation is going to fail.

You'd think that there would be an MFENCE/LFENCE/SFENCE way of solving this more directly, but I haven't found it yet. Or maybe just a LOCK? Maybe a creative false dependency to keep the processor from getting to far ahead? Interesting. Thanks for helping explore this.

[ Parent | on HN ]

Re:Intel i7 loop performance anomaly (2013) by pbsd on Saturday December 16, 2017 @04:11PM (#15942135)

I later realized that padding to 32 bytes didn't make much of a difference, it is the number of vacuous NOP opcodes generated that matters. So it can be simplified to

    mov rcx, 400000000-1
    up:
    nop
    nop
    nop
    add [counter], rcx
    nop
    nop
    nop
    dec rcx
    nop
    nop
    nop
    jnz up
    ret

which probably works fine for the majority of decoding methods, be it MITE, LSD, or DSB.

[ Parent | on HN ]