Hacker News Reader

Comment by RijilV | Hacker News Reader

Worth re-posting Theo's 2007 note about CPU security bugs again:

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

My hunch is that as they suspected these types of issues is what guided them away from things like AVX and other optimizations.

View on HN

OpenBSD was also one of the first operating systems to disable hyper-threading by default due to all the related security issues with this technology. Yet another case of security over speed.

Hyper-threading, at least in the beginning, had limited if any performance improvement when enabled. Windows (XP, 7), at least, was faster at work with hyper-threading disabled.

I'm still waiting for benchmarks which show more than a 5% increase in performance with hyper-threading enabled.

If you haven't seen a >5% performance improvement for any workload with HT/SMT enabled, you're just willfully blinding yourself to benchmark data. It can be closer to 80% than 5%, at least for some reasonable workloads.

They also have a limited number of developers and no interest in performance.

“[N]o interest in performance” is probably a bit unfair, no? It makes it sound like any patch that brought solely performance would be rejected. But it is certainly true that they have much less manpower than the “competition” and that performance takes a backseat relative to other priorities.

No interest in performance means that, no? If they did what you said and rejected performance patches they’d be actively against performance.

No, it just means it’s not the top priority.

If the performance patches would make the code less secure, they would not implement it.

No, it's fair -- they're actively disinterested in patches that improve performance.

Reply on news.ycombinator.com