3 ms·

Benchmarking is always problematic -- what is a good representative workload? All the same, I'd be curious if the ucode update that plugs this bug has affected

• akoboldfrying 3y ago
  In the article by Tavis O. linked elsewhere in comments, he suggests disabling the FSRM CPU feature only as an expensive workaround to be taken only if the microcode can't be updated for some reason. That suggests to me that he, at least, expects the update to do better.
• ReactiveJelly 3y ago
  That would be the conservative thing to do. If there's no limit on microcode updates, if I was Intel, I'd consider doing that first and then speeding it up again later. Based on the 5-second guess that people who update everything regularly will care that we did the right thing for security, and people who hate updates won't be happy anyway, so at least the first update will be secure if they never get the next one. (I think there is a limit on microcode, they seem conservative to release new ones - I don't remember the details)
• kevincox 3y ago
  It's a shame that Google didn't publish numbers. They have very good profiling across all of their servers and probably have incredibly high confidence numbers for the real-world impact on this. (Assuming that your world is lots of copying protocol buffers in C++ and Java)