4 ms·

The thing is, the "slowness" in question is different every time someone wants to talk about it. Because people don't benchmark it, don't actually know what is

The thing is, the "slowness" in question is different every time someone wants to talk about it. Because people don't benchmark it, don't actually know what is slower and by how much, and just go on the "common knowledge" that openbsd is slow. The openbsd is slow meme was going strong in the 1990s, when it didn't support SMP at all and 99% of the people talking about it were using a single CPU.

wahern 12y ago
It's different because the slowness is across the board. FreeBSD and, especially, Linux have optimizations all over the place. A call to time(2) or gettimeofday(2) is hundreds of times faster in Linux than on OpenBSD. In most scenarios the difference doesn't matter. But it does matter in, e.g., an asynchronous network service with lots of events with timeouts being constantly registered. I prefer OpenBSD, and I like that they focus on correctness, bugs, and more high-level features. I run all my personal services on OpenBSD. But commercially and at scale I run Linux, and treat each box as a throw-away in terms of security.
- imanaccount247 12y ago
  >A call to time(2) or gettimeofday(2) is hundreds of times faster in Linux than on OpenBSD Got a link to those benchmarks? Did anyone file a bug report? >But commercially and at scale I run Linux Wouldn't netbsd be a better option?
  - Dylan16807 12y ago
    I doubt it's a bug. That sounds like the overhead of a syscall vs. a memory-mapped page.
    - imanaccount247 12y ago
      How does that make it not a bug? They've repeatedly responded to the "openbsd is slow" meme by pointing out that they do not have the time to benchmark anything, and if people do find slow things they should submit bug reports so they can be fixed. Nobody has ever submitted such a bug report.
      - Dylan16807 12y ago
        It's as fast as any other syscall, it's just lacking in special optimizations.
        imanaccount247 12y ago
        And the part where the developers explicitly say being slower than necessary is a bug and should be reported as such means it is a bug. This honestly is not complicated.
        Dylan16807 12y ago
        If slower than absolutely necessary is a bug I can probably report 99% of lines in the codebase. Perfection is astonishingly difficult.
        imanaccount247 12y ago
        I genuinely don't see how I can take your continued trolling at face value and pretend you are honestly trying to have a conversation.
      - wahern 12y ago
        I mentioned it on the mailing-list a long time ago, when I was more naive about these things. They said I should submit a patch. However, adding virtual syscalls is a non-trivial undertaking, and I'm not experienced enough with kernel internals, which will require wide-ranging changes, including adding special mapping support, hacking the program loader, and tweaking the clock subsystem. Plus you also have to hack userspace. Most importantly you need to add VDSO support to the linker. Refactoring time(2) would be easy, but for higher granularity clocks--gettimeofday(2) and clock_gettime(2)--you need to make careful use of RDTSC and similar instructions for each architecture. _And_ you need to be able to test it well because of synchronization issues on older platforms. On x86, for example, RDTSC is synchronized, but for a long time it varied across cores, and when Intel and AMD fixed that there was a still a small product window where it could vary across CPU packages. It really is an intrusive change.

wahern 12y ago

It's different because the slowness is across the board. FreeBSD and, especially, Linux have optimizations all over the place. A call to time(2) or gettimeofday(2) is hundreds of times faster in Linux than on OpenBSD. In most scenarios the difference doesn't matter. But it does matter in, e.g., an asynchronous network service with lots of events with timeouts being constantly registered. I prefer OpenBSD, and I like that they focus on correctness, bugs, and more high-level features. I run all my personal services on OpenBSD. But commercially and at scale I run Linux, and treat each box as a throw-away in terms of security.

imanaccount247 12y ago
>A call to time(2) or gettimeofday(2) is hundreds of times faster in Linux than on OpenBSD Got a link to those benchmarks? Did anyone file a bug report? >But commercially and at scale I run Linux Wouldn't netbsd be a better option?
- Dylan16807 12y ago
  I doubt it's a bug. That sounds like the overhead of a syscall vs. a memory-mapped page.
  - imanaccount247 12y ago
    How does that make it not a bug? They've repeatedly responded to the "openbsd is slow" meme by pointing out that they do not have the time to benchmark anything, and if people do find slow things they should submit bug reports so they can be fixed. Nobody has ever submitted such a bug report.
    - Dylan16807 12y ago
      It's as fast as any other syscall, it's just lacking in special optimizations.
      - imanaccount247 12y ago
        And the part where the developers explicitly say being slower than necessary is a bug and should be reported as such means it is a bug. This honestly is not complicated.
        Dylan16807 12y ago
        If slower than absolutely necessary is a bug I can probably report 99% of lines in the codebase. Perfection is astonishingly difficult.
        imanaccount247 12y ago
        I genuinely don't see how I can take your continued trolling at face value and pretend you are honestly trying to have a conversation.
    - wahern 12y ago
      I mentioned it on the mailing-list a long time ago, when I was more naive about these things. They said I should submit a patch. However, adding virtual syscalls is a non-trivial undertaking, and I'm not experienced enough with kernel internals, which will require wide-ranging changes, including adding special mapping support, hacking the program loader, and tweaking the clock subsystem. Plus you also have to hack userspace. Most importantly you need to add VDSO support to the linker. Refactoring time(2) would be easy, but for higher granularity clocks--gettimeofday(2) and clock_gettime(2)--you need to make careful use of RDTSC and similar instructions for each architecture. _And_ you need to be able to test it well because of synchronization issues on older platforms. On x86, for example, RDTSC is synchronized, but for a long time it varied across cores, and when Intel and AMD fixed that there was a still a small product window where it could vary across CPU packages. It really is an intrusive change.