5 ms·

Worth re-posting Theo's 2007 note about CPU security bugs again: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2 https://marc.info/?l=openbsd-misc&m=11

by RijilV 3y ago

Worth re-posting Theo's 2007 note about CPU security bugs again: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2 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.

binkHN 3y ago
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.
- hulitu 3y ago
  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.
  - loeg 3y ago
    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.
saagarjha 3y ago
They also have a limited number of developers and no interest in performance.
- ninjin 3y ago
  “[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.
  - saagarjha 3y ago
    No interest in performance means that, no? If they did what you said and rejected performance patches they’d be actively against performance.
    - Gud 3y ago
      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.
  - loeg 3y ago
    No, it's fair -- they're actively disinterested in patches that improve performance.

by RijilV 3y ago

binkHN 3y ago

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.

hulitu 3y ago
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.
- loeg 3y ago
  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.

saagarjha 3y ago

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

ninjin 3y ago
“[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.
- saagarjha 3y ago
  No interest in performance means that, no? If they did what you said and rejected performance patches they’d be actively against performance.
  - Gud 3y ago
    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.
- loeg 3y ago
  No, it's fair -- they're actively disinterested in patches that improve performance.