www.phoronix.com
This shoulder? No? How about this one?
I will not deny that, in an era long long ago, I actually had something like this under my desk. A desk that endured much yelling because the tip of my shoe would hit that turbo button from time to time, making everything grind to a halt. Just not often enough to make it immediately clear why stuff ... just ...... stopped ........... performing. So that was a pain every time. Until I found out that I could do that to co-workers.
You have to imagine this. A top-class programmer just knelt deeper and FreeBSD got twice as fast:
FreeBSD 13 BETA Benchmarks - Performance Is Much Better - Phoronix
What did he do? "Lock-Free" data structures introduced! Every access, every event is first passed through a structure of several parallel queues. Access is disjoint. Each CPU core receives at least 3 queues. While one queue is being written, another is being read and the "Todo Tasks" in the 3rd queue are then sorted, e.g. according to prion criteria. And basically N times. With 16 cores, in order to avoid any collision, I have to reserve 3 queues exclusively for each of its 15 neighboring cores.
That's about it, actually. But this eliminates all synchronization mechanisms, mutexes, locks, semaphores, latches ...
I seriously doubt it. Sounds like a massive architecture change. I'm a-gonna let 13 bake for a while before I adopt it on any production machines.
I read that thread on Heise; it seems to be a debate between Kli-Kla-Klawitter, Urfahraner Auge and Gernotius. It has no concrete information, nothing about what was changed where, and no link to actual kernel changes. It is a general discussion of lock-free data structures in the abstract. Looking at the discussion of what has been changed in version 13, the only thing that I can find is related to lock-free data structures is that a few (certainly very skilled) people did some work on the pf implementation and perhaps bridge networking. But improving pf and networking can not lead to a massive performance change on all applications. Matter-of-fact, I can't understand how improving kernel internal synchronization to use lock-free data structure leads to massive improvements in benchmarks that are user-space CPU and floating point constrained; those benchmarks should be spending nearly zero time in the kernel.
Any news on this? There were a few posts recently where i needed this reaction. Badly.
How about this? :rofl: = ?
Yeah, no thanks. No way am I going swimming in those troll-infested waters.
FreeBSD forums have their share of trolls, too. Good to know that the PTS suite is available as a FreeBSD port. So now it's a matter of figuring out how to run PTS on FreeBSD, or at least learning how to use openbenchmarking.org to harvest the data to back up the outlandish-sounding claims about FreeBSD performance.
