4 ms·
I'm slightly confused by the claim this article makes about performance. It says: > Generally, FreeBSD performs better than Linux - Don’t expect exponential d
by codesections 7y ago
I'm slightly confused by the claim this article makes about performance. It says:
> Generally, FreeBSD performs better than Linux - Don’t expect exponential differences, but many tests have shown that FreeBSD performs better than Linux
In that same line, it links to https://www.phoronix.com/scan.php?page=article&item=3990x-freebsd-bsd&num=2 https://www.phoronix.com/scan.php?page=article&item=3990x-fr... which says:
> Lastly is a look at the geometric mean for all of the benchmarks conducted for this FreeBSD vs. Linux scaling comparison on the AMD Ryzen Threadripper 3990X. In the end, both CentOS Stream and Ubuntu 20.04 (development) delivered similar performance and were basically tied for first.… At 16 cores, RHEL8-based CentOS was about 17% faster than FreeBSD 12.1 while at 128 threads the lead expanded to 28% based upon the geometric mean or 21% when comparing the GCC9 results on FreeBSD 12.1.
- trasz 7y agoWe really need something like Phoronix, but without the fundamental flaws, such as benchmarking compilers instead of the OS, building stuff with wrong flags, and not even providing actually useful numbers - distribution, error bars etc.
- diffeomorphism 7y ago> but without the fundamental flaws, such as benchmarking compilers instead of the OS, building stuff with wrong flags, That is not a flaw but simply benchmarking something else. "This would be the performance if you changed all those settings, fixed these errors etc." might be a nice academic exercise, but "this is the performance you get out of the box" seems much, much more relevant. So you are not benchmarking "the OS" but rather the distribution, which includes whatever compiler version or flags they chose to use. Honest question: If I take the exact same binary and shared libraries and run it on different distros, what am I actually measuring as differences? Kernel configs, filesystem, background processes? Does the distro even matter for that?
- trasz 7y agoThat would be true if they actually measured the applications installed with the system/distribution, or at least built the way they should get built with a given system/distribution - which they don't.
- fuu_dev 7y agoAny comparison will have flaws but Phoronix has a track record for having bad non Linux benchmarks. People complain because they want a fair comparison. Benchmarks are vital. They can give you an estimate of how your application performs. They also often showcase how optimized a product is on different platforms.
- diffeomorphism 7y agoThat answers none of my questions?
- trasz 7y agoIf you get different results, the difference comes from the parts that hadn't changed. So if you were to run the exact same binaries in different environment (different operating system, or same operating system but built or configured differently) and you got different results, you'd be measuring differences between environments. But that's kind of obvious, so why are you asking this?
- diffeomorphism 7y agoBecause they proposed "fixing" the benchmarks by doing this, at which point I am asking what you hope to see in the benchmark if everything is the same. They consider difference due to compiler versions to be "wrong", differences in flags to be "wrong" etc. . So "the difference comes from the parts that hadn't changed", yeah which ones would you permit to change to consider the benchmark not "wrong"?
- trasz 7y ago
- partomniscient 7y agoThere was a period of time where FreeBSD performed much better under load (particularly under a high network load). Unfortunately as a side effect you get a lot of people quoting "FreeBSD performs better than Linux" without context or under what scenarios.
- trasz 7y agoThere were many different periods where FreeBSD performed better than Linux under some loads. The same is true in the other direction. Generally speaking, "X performs better than Y" is meaningless without specifying the workload.