Hacker News Reader

Comment by jwr | Hacker News Reader

I did my own testing a while back, because I wanted to measure if these actually make a performance impact for my use case.

Net result: they do not. For my use case (Clojure/JVM and ClojureScript compilation), compile times did not get shorter. There seemed to be a slight improvement, but it was below the level of measuring noise (which was around 8%).

My conclusion was that while the system might indeed be faster by several percent, it is not measurable in my case, so I should not even bother, given the possible risks.

View on HN

> Net result: they do not. For my use case (Clojure/JVM and ClojureScript compilation), compile times did not get shorter. There seemed to be a slight improvement, but it was below the level of measuring noise (which was around 8%).

I think the level of measuring noise is 0.5%, at least that is what low level system programmers generally consider as noise...

I don't think anyone else gets to say how much noise the GP saw in their test.

How can you know that information?

Compile times for my project are around 2m15s to 2m30s. Since this work involves lots of CPU (some single-threaded, some multi-threaded work) and I/O, the spread mentioned above is what I get with multiple measurements.

While it's true that without the mitigations times were much closer to the 2:15 mark, there were still outliers at 2:24. Which means it's hard to draw any meaningful conclusions.

Not sure where you got the "0.5%" figure from.

Nice work. Anyone claiming performance improvements without an accompanying benchmark that is relevant to your usecase is wasting your time.

My experience was different. My laptop boots in half the time with these mitigations disabled, and is noticeably much faster to use.

That's weird. I don't think anyone has measured these mitigations at a 50% perf hit even on crafted workloads. I wonder if something else is going on.

15% of pure cpu, but that doesn't take the consequences of the CPU improvement in other systems (e.g. crypto fs leading to higher iop rates, etc).

Running insecure performance enhancing kernel mods to speed up crypto fs....

It's a self defeating performance tip!

TBH there's different threat models there. A crypto fs makes sense if you're worried about a box getting stolen, while spectre/etc aren't a concern if you're running regular userland stuff on a single-user box.

same conclusion on the hardware i tested with

Reply on news.ycombinator.com