4 ms·
The mitigations don't affect CPU bound benchmarks [1] which don't call into the kernel or use specific user-space mitigations, so it won't matter here. [1] The
by BeeOnRope 7y ago
The mitigations don't affect CPU bound benchmarks [1] which don't call into the kernel or use specific user-space mitigations, so it won't matter here.
[1] There are some rare exceptions, such as https://travisdowns.github.io/blog/2019/03/19/random-writes-and-microcode-oh-my.html https://travisdowns.github.io/blog/2019/03/19/random-writes-... , but it is unlikely to matter here.
- fulafel 7y agoSmt on/off has a large effect.
- BeeOnRope 7y agoIt's a single threaded test, so I don't think that matters here.
- fulafel 7y agoTrue. But generally it affects cpu bound benchmarks.
- NullPrefix 7y agoSMT off might mean not enough spare threads to run the OS telemetry.
- BeeOnRope 7y agoThis is Linux but I don't think that would be true even on Windows.
- amluto 7y agoThat may have been true, but it is rather dramatically false with the new JCC erratum workaround. It’s also false if you’re using a hypervisor that mitigates the iTLB multihit issue.
- BeeOnRope 7y agoGood point, I forgot about that one, although here there is only a single hot loop with one jump so a high chance the crossing doesn't occur, and even if it does the IPC is low enough the legacy decoder probably does OK (although it adds a cycle or two to misprediction recovery, which matters here). So it's something worth checking. No hypervisor involved.