Hacker News Reader

Comment by tasty_freeze | Hacker News Reader

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 CPU performance, eg, it diverts the "fast short rep move" path to just use the "bad for short moves but great for long moves" version.

View on HN

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.

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)

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)

Reply on news.ycombinator.com