11 ms·
OpenBSD is so fast, I had to modify the program slightly to measure itself
- rurban 1y agoNo, generally Linux is at least 3x faster than OpenBSD, because they don't care much for optimizations.
- kleiba 1y agoPretty broad statement(s).
- shmerl 1y agoIt's talking about a specific case: https://infosec.exchange/@jann/115022521451508325 https://infosec.exchange/@jann/115022521451508325
- farhaven 1y agoOpenBSD is a lot faster in some specialized areas though. Random number generation from `/dev/urandom`, for example. When I was at university (in 2010 or so), it was faster to read `/dev/urandom` on my OpenBSD laptop and pipe it over ethernet to a friend's Linux laptop than running `cat /dev/urandom > /dev/sda` directly on his. Not by just a bit, but it was a difference between 10MB/s and 100MB/s.
- cogman10 1y ago/dev/urandom isn't a great test, IMO, simply because there are reasonable tradeoffs in security v speed. For all I know BSD could be doing 31*last or something similar. The algorithm is also free to change.
- chowells 1y agoUm... This conversation is about OpenBSD, making that objection incredibly funny. OpenBSD has a mostly-deserved reputation for doing the correct security thing first, in all cases. But that's also why the rng stuff was so much faster. There was a long period of time where the Linux dev in charge of randomness believed a lot of voodoo instead of actual security practices, and chose nonsense slow systems instead of well-researched fast ones. Linux has finally moved into the modern era, but there was a long period where the randomness features were far inferior to systems built by people with a security background.
- tptacek 1y agoOpenBSD isn't meaningfully more secure than Linux. It probably was 20 years ago. Today it's more accurate to say that Linux and OpenBSD have pursued different security strategies --- there are meaningful differences, but they aren't on a simple one-dimensional spectrum of "good" to "bad". (I was involved, somewhat peripherally, in OpenBSD security during the era of the big OpenBSD Security Audit).
- sugarpimpdorsey 1y agoHaven't they had some embarrassing RCEs in the not too distant past? It kind of calls into question the significance of that claim about holes "in the default install" - even Windows ships without any services exposed these days. Ultimately, they suffer from a lack of developer resources. Which is a shame because it's a wonderfully integrated system (as opposed to the tattered quilt that is every Linux distro). But I suspect it's the project leadership that keeps more people away.
- user3939382 1y agoI’ve found the OpenBSD community to have a bad/snobbish attitude which could just be a coincidence, no idea. I’ve always liked NetBSD which I never had that problem with.
- kaskjdhaas 1y agoI remember a discussion with an OpenBSD developer whose answer to the lack of a journaling file system was to simply have a UPS, like any normal computer user should have (there are hobby operating systems with journaling FS, but due to the antique development model, OpenBSD developers can't do significant work like a new file system).
- anthk 1y agoThey could port WAPBL from NetBSD in no time.
- sillystuff 1y agoI think you meant to say /dev/random, not /dev/urandom. /dev/random, on linux used to stall waiting for entropy from sources of randomness like network jitter, mouse movement, keyboard typing. /dev/urandom has always been fast on Linux. Today, linux /dev/random mainly uses an RNG after initial seeding. The BSDs always did this. On my laptop, I get over 500MB/s (kernel 6.12) . IIRC, on modern linux kernels, /dev/urandom is now just an alias to /dev/random for backward compatibility.
- tptacek 1y agoThere's no reason for normal userland code not part of the distribution itself ever to use /dev/random, and getrandom(2) with GRND_RANDOM unset is probably the right answer for everything. Both Linux and BSD use a CSPRNG to satisfy /dev/{urandom,random} and getrandom, and, for future-secrecy/compromise-protection continually update their entropy pools with hashed high-entropy events (there's ~essentially no practical cryptographic reason a "seeded" CSPRNG ever needs to be rekeyed, but there are practical systems security reasons to do it).
- somat 1y agoAt one point probably 10 years ago I had linux vm guests refuse to generate gpg keys, gpg insisted it needed the stupid blocking random device, and because the vm guest was not getting any "entropy" the process went nowhere. As an openbsd user naturally I was disgusted, there are many sane solutions to this problem, but I used none of them. Instead I found rngd a service to accept "entropy" from a network source and blasted it with the /dev/random from a fresh obsd guest on the same vm host. Mainly out of spite. "look here you little shit, this is how you generate random numbers"
- craftkiller 1y agoQemu added support for VirtIO RNG in 2012 [0] so depending on how accurate that 10 year figure is, you also could have used that to make your VM able to use the host system's entropy. [0] https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG
- sgarland 1y agoOpenBSD switched their PRNG to arc4random in 2012 (and then ChaCha20 in 2014); depending on how accurate your time estimate is, that could well have been the cause. Linux switched to ChaCha20 in 2016. Related, I stumbled down a rabbit hole of PRNGs last year when I discovered [0] that my Mac was way faster at generating UUIDs than my Linux server, even taking architecture and clock speed into account. Turns out glibc didn’t get arc4random until 2.36, and the version of Debian I had at the time didn’t have 2.36. In contrast, since MacOS is BSD-based, it’s had it for quite some time. [0]: https://gist.github.com/stephanGarland/f6b7a13585c0caf9eb64b035b15b9882 https://gist.github.com/stephanGarland/f6b7a13585c0caf9eb64b...
- deleted 1y ago[deleted]
- nicce 1y agoRather they care about the security. The same mitigations in Linux would likely make it even slower.
- jedberg 1y ago"It depends" Faster is all relative. What are you doing? Is it networking? Then BSD is probably faster than Linux. Is it something Linux is optimized for? Then probably Linux. A general benchmark? Who knows, but does it really matter? At the end of the day, you should benchmark your own workload, but also it's important to realize that in this day and age, it's almost never the OS that is the bottleneck. It's almost always a remote network call.
- the_plus_one 1y agoIs it just me, or is there some kind of asteroid game shooting bullets at my cursor while I try to read this [1]? I hate to sound mean, but it's a bit distracting. I guess it's my fault for having JavaScript enabled. [1]: https://flak.tedunangst.com/script.js https://flak.tedunangst.com/script.js
- nomel 1y agoAnd, if it hits, your cursor disappears! I wish there was some explosion.
- bigstrat2003 1y agoNo, it's the website's fault for doing stupid cutesy stuff that makes the page harder to read. Don't victim-blame yourself here.
- nomel 1y agoYou should ask for a refund!
- stavros 1y agoI really don't understand this "everything must be 100% serious all the time". Why is it stupid?
- apodik 1y agoI generally think stuff like that make the web much more interesting. In this case it was distracting though.
- Gualdrapo 1y agoThe HN hivemind decries the lack of humanity and personality of the internet of nowadays but at the same time wants every website to be 100% text, no JS, no CSS because allegedly nobody needs CSS and, if you dare to do something remotely "fancy" with the layout, you have to build it with <table>s.
- haunter 1y agoIn my mind faster = the same game with the same graphics settings have more FPS (I don’t even know you could actually start mainstream games on BSD or not)
- nine_k 1y agoIsn't it mostly limited by GPU hardware, and by binary blobs that are largely independent from the host platform?
- haunter 1y agoGames run better under Linux (even if they are not-native but with Proton/Wine) than on Windows 11 so the platform does matter https://news.ycombinator.com/item?id=44381144 https://news.ycombinator.com/item?id=44381144
- extraisland 1y agoIt annoys me when people claim this. It depends on the game, distro, proton version, what desktop environment, plus a lot of other things I have forgotten about. Also latency is frequently worse on Linux. I play a lot of quick twitch games on Linux and Windows and while fps and frame times are generally in the same ballpark, latency is far higher. Other problems is that proton compatibility is all over the place. Some of the games valve said were certified don't actually work well, mods can be problematic, and generally you end up faffing with custom launch options to get things working well.
- zelphirkalt 1y agoMany of those games mysteriously fail to work for me, almost like Proton has a problem on my system in general and I am unable to figure it out. However, in the past I got games that are made for Windows to work better on WINE than on Windows. One of those games is Starcraft 2 when it came out. On Windows it would always freeze in one movie/sequence of the single player campaign, which made it actually unplayable on Windows, while after some trial and error, I managed to get a fully working game on GNU/Linux, and was able to finish the campaign. This goes to show, that the experience with Proton and different hardware and whatever it is in system configuration is highly individual, but also, that games can indeed run better using WINE or Proton than on the system they were made for.
- dang 1y agoThe article title is too baity to fit HN's guidelines (https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html) so I replaced it with a phrase from the article that's hopefully just baity enough.
- cout 1y agoInteresting. I tried to follow the discussion in the linked thread, and the only takeaway I got was "something to do with RCU". What id the simplified explanation?
- viraptor 1y agoWhen 2 threads are allocating sockets sequentially, they fight for the locks. If you preallocate a bigger table by creating fd 666 first, the lock contention goes away.
- JdeBP 1y agoIt's something that has always been interesting about Windows NT, which has a multi-level object handle table, and does not have the rule about re-using the lowest numbered available table index. There's scope for reducing contention amongst threads in such an architecture. Although: 1. back in application-mode code the language runtime libraries make things look like a POSIX API and maintain their own table mapping object handles to POSIX-like file descriptors, where there is the old contention over the lowest free entries; and 1. in practice the object handle table seems to mostly append, so multiple object-opening threads all contend over the end of the table.
- the8472 1y agolowest-number-reuse is also a robustness issue. If multi-threaded programs UAF or double-free a file descriptor they likely end up touching FDs owned by other parts of the program which can result in various kinds of corruption and memory-unsafety. Assigning numbers from a large domain, either randomly or from a permutation sequence, would massively reduce that probability and manifest in prompt errors instead.
- loeg 1y agoI want an alternative unix ABI that doesn't guarantee lowest-reuse for this exact reason. I suppose you could (almost) just hijack the close call and replace it with a dup2 of /dev/null or something (but then you'd miss close errors).
- agambrahma 1y agoSo ... essentially testing file descriptor allocation overhead
- loeg 1y agoSort of. Fd table size, which is slightly different than fds (once you reach the ulimit, there's no need to resize it larger); and only in multithreaded programs.
- asveikau 1y agoMy guess is it has something to do with the file descriptor table having a lot of empty entries (the dup2(0, 666) line.) Now time to read the actual linked discussion.
- wahern 1y agoI think dup2 is the hint, but in the example case the dup2 path isn't invoked--it's conditioned on passing an argument, but the test runs are just `./a.out`. IIUC, the issue is growing the file descriptor table. The dup2 is a workaround that preallocates a larger table (666 > 256 * 2)[1], to avoid the pathological case when a multi-threaded process grows the table. From the linked infosec.exchange discussion it seems the RCU-based approach Linux is using can result in some significant latency, resulting in much worse performance in simple cases like this compared to a simple mutex[2]. [1] Off-by-one. To be more precise, the state established by the dup2 is (667 > 256 * 2), or rather (667 > 3 + 256 * 2). [2] Presumably what OpenBSD is using. I'd be surprised if they've already imported and adopted FreeBSD's approach mentioned in the linked discussion, notwithstanding that OpenBSD has been on an MP scalability tear the past few years.
- themafia 1y agoYea, well, I had to modify your website to make it readable. Why do people do this?
- opan 1y agoIt looks good to me on mobile. High contrast, lines aren't too long. What issue did you have?
- themafia 1y agoThere are two widgets in the lower left and lower right corners of the page which constantly shoot little bullets all over the screen chasing your mouse pointer. In the steady state on my screen there are about 20 sprites constantly moving across the page. There was no obvious way to disable them other than inspecting the page and deleting the widgets from the page. If you want me to read your site, and you want to put detailed technical information on it, please don't add things like this without an off switch.
- antennafirepla 1y agoVery frustrating, I read with the mouse pointer and this made it impossible.
- SoftTalker 1y agoThat was added fairly recently I’d guess as a joke but I’m not in on the reasons.
- GuB-42 1y agoWeird, as soon as my mouse pointer gets hit by one of the bullets, the shooters disappear until I refresh the page. Not getting hit for more than a few seconds is actually rather tricky as the rate of fire increases. I didn't even notice them at first as my mouse pointer got shot by the first couple of bullets. Maybe the behavior changed.
- sweetjuly 1y agoA better title: a pathological test program meant for Linux does not trigger pathological behavior on OpenBSD
- apgwoz 1y agoSurely you must be new to tedu posts…
- ameliaquining 1y agoStill worth avoiding having the HN thread be about whether OpenBSD is in general faster than Linux. This is a thing I've seen a bunch of times recently, where someone gives an attention-grabbing headline to a post that's actually about a narrower and more interesting technical topic, but then in the comments everyone ignores the content and argues about the headline.
- st_goliath 1y ago> This is a thing I've seen a bunch of times recently ... > ... in the comments everyone ignores the content and argues about the headline. Surely you must be new to Hacker News…
- ameliaquining 1y agoIt was more that there were a couple of particularly frustrating recent examples that happened to come to my attention. Of course this has always been a problem.
- chasil 1y agoAs I understand it, OpenBSD is similar to Linux 2.2 architecturally in that there is a lock that prevents (most) kernel code from running on more than one (logical) CPU at once. We do hear that some kernel system calls have moved out from behind the lock over time, but anything requiring core kernel functionality must wait until the kernel is released from all other CPUs. The kernel may be faster in this exercise, but is potentially a constrained resource on a highly loaded system. This approach is more secure, however.
- Const-me 1y agoNot sure if that’s relevant, but when I do micro-benchmarks like that measuring time intervals way smaller than 1 second, I use __rdtsc() compiler intrinsic instead of standard library functions. On all modern processors, that instruction measures wallclock time with a counter which increments at the base frequency of the CPU unaffected by dynamic frequency scaling. Apart from the great resolution, that time measuring method has an upside of being very cheap, couple orders of magnitude faster than an OS kernel call.
- sa46 1y agoIsn't gettimeofday implemented with vDSO to avoid kernel context switching (and therefore, most of the overhead)? My understanding is that using tsc directly is tricky. The rate might not be constant, and the rate differs across cores. [1] [1]: https://www.pingcap.com/blog/how-we-trace-a-kv-database-with-less-than-5-percent-performance-impact/ https://www.pingcap.com/blog/how-we-trace-a-kv-database-with...
- Dylan16807 1y agoIf you have something newer than a pentium 4 the rate will be constant. I'm not sure of the details for when cores end up with different numbers.
- quotemstr 1y agoWizardly workarounds for broken APIs persist long after those APIs are fixed. People still avoid things like flock(2) because at one time NFS didn't handle file locking well. CLOCK_MONOTONIC_RAW is fine these days with the vDSO.
- denotational 1y agoSadly GPFS still doesn’t support flock(2), so I still avoid it.
- quotemstr 1y agoDoesn't it? https://sambaxp.org/archive-data-samba/sxp09/SambaXP2009-DATA/Henning_Henkel.pdf https://sambaxp.org/archive-data-samba/sxp09/SambaXP2009-DAT... It would be weird, even for AIX, to support POSIX byte range locks and not the much simpler flock.
- znpy 1y agothe first step in benchmarking software is to use the same hardware. the author failed the first step. everything that follows is then garbage.
- saagarjha 1y agoYou do understand that people who know how to benchmark things don’t actually need to conform to the rules of thumb that are given to non-experts so they don’t shoot themselves in the foot, right? Do you also write off rally drivers because they have their feet on both pedals?
- znpy 1y agoi don't know about you but i did my fair share of benchmarking and performance engineering. the first thing that you learn in that area is that unless you're comparing specific configuration of apples to apples, along with a specific configuration of the workloads, you're basically doing children play. i mean, it's fine to play and observe, but it's just play. it's not anything to take seriously.
- saagarjha 1y agoPlay is not garbage. A lot of performance engineering is not taking yourself seriously. Signed, someone who is a professional performance engineer :)
- GTP 1y agoBy leaving my finger on the screen, I accidentally triggered an easter egg of two "cannons" shooting squares. Did anyone else notice it?
- evanjrowley 1y agoI also saw it, and it happened on a non-touch computer screen.
- pan69 1y agoHappened for me on my normal desktop browser, cute but distracting. It also made my mouse cursor disappear. I had to move my mouse outside the browser window to make it visible again.
- IFC_LLC 1y agoI'll be honest, this was the first time when I was unhappy with an easter egg and was unable to finish reading the article because of it. Triggered on a safari on mac.
- M_r_R_o_b_o_t_ 1y agoYe
- uwagar 1y agothe bsd people seem to enjoy measuring and logging a lot.
- sugarpimpdorsey 1y agoOpenBSD is many things, but 'fast' is not a word that comes to mind. Lightweight? Yes. Minimalist? Definitely. Compact? Sure. But fast? No. Would I host a database or fileserver on OpenBSD? Hell no. Boot times seem to take as long as they did 20 years ago. They are also advocates for every schizo security mitigation they can dream up that sacrifices speed and that's ok too. But let's not pretend it's something it's not.
- ThinkBeat 1y agoYou must run a different branch of OpenBSD than I.
- chasil 1y agoIn some defense of the parent post, a new kernel is relinked at every boot. This load is noticeable. This is aslr on steroids, and it does vastly increase kernel attack complexity, but it is a computational and I/O load that no version of Linux imposes that I know. Relinking the C library is relatively quick in comparison.
- sillywalk 1y ago> a new kernel is relinked at every boot Known as OpenBSD kernel address randomized link (KARL)[0][1] Also, libc, and libcrypto are re-linked at boot [2]. And sshd [3]. [0] https://marc.info/?l=openbsd-tech&m=149732026405941 https://marc.info/?l=openbsd-tech&m=149732026405941 [1] https://news.ycombinator.com/item?id=14709256 https://news.ycombinator.com/item?id=14709256 [2] https://news.ycombinator.com/item?id=14710180 https://news.ycombinator.com/item?id=14710180 [3] https://marc.info/?l=openbsd-cvs&m=167407459325339&w=2 https://marc.info/?l=openbsd-cvs&m=167407459325339&w=2
- rs_rs_rs_rs_rs 1y ago>aslr on steroids, and it does vastly increase kernel attack complexity That's quite the statement, in reality KARL is a mild incovenience at best(for a more sober look on it see https://isopenbsdsecu.re/mitigations/karl/ https://isopenbsdsecu.re/mitigations/karl/)
- eyberg 1y agoThis is kind of a stupid "benchmark" but if we're going to walk down this road: linux: elapsed: 0.019895s nanos (running on said linux): elapsed: 0.000886s
- kaskjdhaas 1y ago[dead]
- 1vuio0pswjnm7 1y ago"Usually it's the weirdo benchmark that shows OpenBSD being 10x slower, so this one is definitely going in the collection." Could it be https://web.archive.org/web/20031020054211if_/http://bulk.fefe.de:80/scalability/ https://web.archive.org/web/20031020054211if_/http://bulk.fe... or is there another one
- ychnlt 1y ago[dead]
- u64x086a 1y agoWhat about the FreeBSD?
- u64x086a 1y agoWhat about this on FreeBSD? It's possible to reach the same results?
- loeg 1y agoFreeBSD doesn't use RCU in the kernel, so it is unlikely to have the exact same ~bug as Linux here. Any naive implementation will have the same decent performance OpenBSD does for this program. FreeBSD's equivalent implementation lives here (it does all of this under an exclusive lock): http://fxr.watson.org/fxr/source/kern/kern_descrip.c#L1882 http://fxr.watson.org/fxr/source/kern/kern_descrip.c#L1882 It doesn't use RCU, but does do a kind of bespoke refcounted retention of old versions of the fdtable on a free list.
- owl_vision 1y agoWhat were the resource setups? How do they compare to linux resource setups? Defaults in current are in etc.amd64/login.conf. https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc/etc.amd64/login.conf?rev=1.27&content-type=text/plain https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/etc... (p.s.: the bubble are cool. highly distracting to me, hence I could not read the article in full.)
- loeg 1y agoThe Linux one is essentially measuring a (surprising) sleep; not resource limited.
- 1970-01-01 1y agoA better way to do that (sorry) is to increase the loading instead of modifying the test. I'm happy to hear reasons why their way could be a better benchmark.
- loeg 1y agoThe phenomenon being measured on Linux is a ~one-off event in a process' lifetime.
- deleted 1y ago[deleted]