4 ms·

Does anyone have any insight on why performance on OpenBSD is so much poorer? I'm really curious. I would have predicted the opposite: that OpenBSD is faster on

by bollu 6y ago

Does anyone have any insight on why performance on OpenBSD is so much poorer? I'm really curious. I would have predicted the opposite: that OpenBSD is faster on account of its leaner.

iddan 6y ago
Probably utilisation of hardware
iuguy 6y ago
Lots of different reasons, but common ones include: 1. No binary blobs, so hardware acceleration can be missed. 2. There have been issues with specific apps e.g. Firefox that seem optimised for things that OpenBSD doesn't do. 3. Historically SMP/Hyperthreading support hasn't been as performant as it is on other platforms. In some cases this is due to prioritising security over performance - e.g. speculative cache execution bugs.
- LargoLasskhyfv 6y ago
  In single-core/early dualcore times on then contemporary PC-hardware, I had the opportunity to compare OpenBSD vs. NetBSD vs. FreeBSD. Though I didn't use them 'shrink-wrapped', but rather like one would do 'Linux from Scratch', or at least a very riced Gentoo :) Anyways, my hardware was supported perfectly on all of them, so no problems there. This way FreeBSD was only slightly faster than NetBSD, and i could have 132x60 textmode on its console, which didn't work at the time for NetBSD, and many, many ports of software. But I didn't need them all, and it felt a little more bloated. Since my goal was full desktop with KDE3 I didn't care much about textmode and went with NetBSD. It flew, rock-solid, unkaputtbar! While OpenBSD, at the times with the parts of KDE3 which were available for it had unexplainable periodic hiccups, not only during load, but light desktop use when no swap was in use at all! That felt very weird, and after a few months I discarded it, since other users and developers/contributors of it which I've spoken to in person(sometimes looking at me like I'd be an alien from outer space for using it as desktop) didn't have more to offer than right tool for the job, yadda yadda... Since then I'm following its progress from afar, only mildly interested. PF and ACKPRI were nice, but at least ACKPRI could be had by other means elsewhere, or some appliance. So... right tool for the job, I guess? edit: the hiccups didn't only happen while in X/KDE. Also when no Xserver at all was running, just doing things on the console, also while no swap was in use. 2nd edit: I pivoted to Arch from there, which in direct comparison to the riced NetBSD flew hypersonic, but wasn't as unkaputtbar (though only slightly less so), but saved much compile time :)
implements 6y ago
I’ve a dim memory that a version of Firefox was slow because it frequently called a system function that most OSs implement “quick and dirty” but OpenBSD did “slower, but correct”, so perhaps it’s down to an accumulation of that approach repeated throughout the system?
- easytiger 6y ago
  Not tremendously helpful without discussing examples. Do you have more information?
  - nix23 6y ago
    Next time use a search engine for yourself: https://flak.tedunangst.com/post/firefox-vs-rthreads https://flak.tedunangst.com/post/firefox-vs-rthreads
    - easytiger 6y ago
      Are you quite serious?
      - nix23 6y ago
        Yes http://letmegooglethat.com/?q=Firefox+slow+on+Openbsd http://letmegooglethat.com/?q=Firefox+slow+on+Openbsd
    - implements 6y ago
      The very one! Thank you.
    - msla 6y ago
      Search engines don't always bring up reputable sources. Case in point, perhaps?
michaelmrose 6y ago
I think the truth is that being fast is the result of doing things smarter and being lean means doing less. Intuitively it seems like doing less ought to lead to fewer defects not better performance.
scns 6y ago
Filesystem performance

by bollu 6y ago

Does anyone have any insight on why performance on OpenBSD is so much poorer? I'm really curious. I would have predicted the opposite: that OpenBSD is faster on account of its leaner.

iddan 6y ago

Probably utilisation of hardware

iuguy 6y ago

Lots of different reasons, but common ones include: 1. No binary blobs, so hardware acceleration can be missed. 2. There have been issues with specific apps e.g. Firefox that seem optimised for things that OpenBSD doesn't do. 3. Historically SMP/Hyperthreading support hasn't been as performant as it is on other platforms. In some cases this is due to prioritising security over performance - e.g. speculative cache execution bugs.

LargoLasskhyfv 6y ago
In single-core/early dualcore times on then contemporary PC-hardware, I had the opportunity to compare OpenBSD vs. NetBSD vs. FreeBSD. Though I didn't use them 'shrink-wrapped', but rather like one would do 'Linux from Scratch', or at least a very riced Gentoo :) Anyways, my hardware was supported perfectly on all of them, so no problems there. This way FreeBSD was only slightly faster than NetBSD, and i could have 132x60 textmode on its console, which didn't work at the time for NetBSD, and many, many ports of software. But I didn't need them all, and it felt a little more bloated. Since my goal was full desktop with KDE3 I didn't care much about textmode and went with NetBSD. It flew, rock-solid, unkaputtbar! While OpenBSD, at the times with the parts of KDE3 which were available for it had unexplainable periodic hiccups, not only during load, but light desktop use when no swap was in use at all! That felt very weird, and after a few months I discarded it, since other users and developers/contributors of it which I've spoken to in person(sometimes looking at me like I'd be an alien from outer space for using it as desktop) didn't have more to offer than right tool for the job, yadda yadda... Since then I'm following its progress from afar, only mildly interested. PF and ACKPRI were nice, but at least ACKPRI could be had by other means elsewhere, or some appliance. So... right tool for the job, I guess? edit: the hiccups didn't only happen while in X/KDE. Also when no Xserver at all was running, just doing things on the console, also while no swap was in use. 2nd edit: I pivoted to Arch from there, which in direct comparison to the riced NetBSD flew hypersonic, but wasn't as unkaputtbar (though only slightly less so), but saved much compile time :)

implements 6y ago

I’ve a dim memory that a version of Firefox was slow because it frequently called a system function that most OSs implement “quick and dirty” but OpenBSD did “slower, but correct”, so perhaps it’s down to an accumulation of that approach repeated throughout the system?

easytiger 6y ago
Not tremendously helpful without discussing examples. Do you have more information?
- nix23 6y ago
  Next time use a search engine for yourself: https://flak.tedunangst.com/post/firefox-vs-rthreads https://flak.tedunangst.com/post/firefox-vs-rthreads
  - easytiger 6y ago
    Are you quite serious?
    - nix23 6y ago
      Yes http://letmegooglethat.com/?q=Firefox+slow+on+Openbsd http://letmegooglethat.com/?q=Firefox+slow+on+Openbsd
  - implements 6y ago
    The very one! Thank you.
  - msla 6y ago
    Search engines don't always bring up reputable sources. Case in point, perhaps?

michaelmrose 6y ago

I think the truth is that being fast is the result of doing things smarter and being lean means doing less. Intuitively it seems like doing less ought to lead to fewer defects not better performance.

scns 6y ago

Filesystem performance