Clear Linux Beats CentOS, openSUSE, and Ubuntu in (Enterprise) Benchmark Tests (phoronix.com) 136
An anonymous reader writes: Recently completed Linux distro benchmarks by Phoronix show Intel's Clear Linux is the most powerful on x86 hardware. A six-way, enterprise-focused Linux distro comparison show Clear Linux being the fastest with a Core i9 and Xeon systems, easily beating CentOS, openSUSE, and Ubuntu in a majority of the tests.
When doing an 11-way Linux distro boot test they also found Clear Linux easily booted the fastest followed by the Clear-inspired Solus distribution. Clear Linux does work on AMD hardware and works on Intel CPUs back to Sandy Bridge but leverages its speed from optimized compiler settings, specially built libraries capable of AVX instructions on supported systems, a specially tuned kernel configuration, and other optimizations/patches.
Debian 9.2 and Fedora 27 "ended up being dropped from this article due to data overload," the article concludes, "and those distributions really not offering anything really different in terms of the performance."
When doing an 11-way Linux distro boot test they also found Clear Linux easily booted the fastest followed by the Clear-inspired Solus distribution. Clear Linux does work on AMD hardware and works on Intel CPUs back to Sandy Bridge but leverages its speed from optimized compiler settings, specially built libraries capable of AVX instructions on supported systems, a specially tuned kernel configuration, and other optimizations/patches.
Debian 9.2 and Fedora 27 "ended up being dropped from this article due to data overload," the article concludes, "and those distributions really not offering anything really different in terms of the performance."
Re: Double Penetration! (Score:2)
Never used Internet Explorer? (Score:2)
You assume newer is always faster. That's not necessarily so. Internet Explorer got slower and slower with each version. Vista was slower than XP. In the Linux world, going from 32-bit to 64-bit makes it slower, all other things being equal. It's entirely *possible* than a newer systemd will slow things down as it gets bigger and bigger - compare an old, small editor such as vi/vim vs the newest MS Word. Newer and bigger sure can be slower.
On the other hand, as someone else commented:
> Linux distro pro
Re: (Score:2)
Re: (Score:2)
That's actually a handwave statement. Scientifically, how do they know what they've selected is more-stable?
I've had more data loss on CentOS boxes than anything else. There's also an issue with e1000 NICs where the in-kernel driver crashes every couple days if under moderate network load, so you need to build an out-of-tree driver--and RedHat doesn't do out-of-tree drivers because it's "not stable". To get networking to work again, you have to reboot, as the driver won't unload.
The solution was to s
Re: (Score:2)
Scientifically, they wouldn't because the OS is logic and many layers away from even the applied science. But there are many ways you can objectively select for stability over performance. For instance, buffers, queues, handle counts, etc are more stable when over-sized and more performant when trimmed because the larger these things are the more overhead they carry but the lower the chance of overrun. Compiling to a lower common denomi
Re: (Score:2)
For instance, buffers, queues, handle counts, etc are more stable when over-sized and more performant when trimmed because the larger these things are the more overhead they carry but the lower the chance of overrun.
Actually, allocating a larger buffer doesn't necessarily incur more performance overhead. On-stack buffers are identical performance cost at any size; however, thread stacks don't grow, so a larger on-stack buffer can lead to crashes depending on usage--something that hit one of the JSON libraries which was allocating 128k buffers. Large malloc() calls at the user level may search through a tree by size, thus not incurring a specific performance overhead or savings compared to small malloc() calls; small
Re: (Score:2)
Re: (Score:2)
If you are asserting that what I really meant, that tuning values for disk, filesystem, network stack, process limits, etc can and do in many cases impact stability and performance and that it is not possible to select values that are more cautious defaults at the expense of leaner defaults I do not concede that point.
Well, no, the system won't crash or fail from these things. Also, RHEL has the same out-of-the-box process limits and filesystem tunables as everything else out there--and, for the longest time, raising the max file handles would actually cause a bug to show up in glibc (Drepper spent a decade telling everyone who wanted support for more than 1024 open files in a specific glibc function that they were morons; people worked around it, although it caused Apache to crash now and then). The per-thread stack
Re: (Score:2)
"Well, no, the system won't crash or fail from these things."
I think we have different definitions at play. In my world routine security updates should not break the system. In fact I should be able to set them to automatic on production and nothing should break. In the real world I need exclusion lists and run through a test environment but unless there is a major revision change there is very very rarely a problem updating the system in RHEL betwe
Re: (Score:2)
In my world routine security updates should not break the system. In fact I should be able to set them to automatic on production and nothing should break.
My experience has been that security updates on RHEL may bring breakage, while on Ubuntu I just leave the automatic updater on.
RHEL "service packs" are bullshit. A RHEL "Service pack" is allowed to be equivalent to an Ubuntu major release: they can upgrade the versions of any software they choose, and often do drop software from the repos, add new software, and upgrade the major version of software. When they do this, they immediately cease supporting the old software. Again: RHEL replaced Apache 2.2
Re: (Score:2)
You assume newer is always faster. That's not necessarily so. Internet Explorer got slower and slower with each version. Vista was slower than XP.
And every version of Windows since Vista has been faster and leaner. Firefox, after years of bloating up, just got a substantial speedup.
In these cases, it was determined that *performance* was a feature worth chasing after, and a lot of effort went into optimizing and streamlining code. I certainly agree you can't always assume that newer is faster, but it can be if it's a priority for developers.
Re: (Score:2)
It really depends where you look.
Moving from 32 bit to 64 bit seemed slower because it has double the size of the opt-code stored in the executable. So more time is taking transferring data from slowest part of the computer. However once the data is there, especially with larger numbers, and the extra RAM so much more can be done. How we use computers had also changed over the past 40 years too. We use to run one application. What was called the OS was mostly a boot loader and when the Application was exe
Re: (Score:1)
I'm so glad I stayed up for this (Score:5, Insightful)
Linux distro produced by Intel, tuned by Intel for latest Intel hardware, works fastest of any distro on latest Intel hardware. Shocking!
Re: I'm so glad I stayed up for this (Score:2)
I bet itâ(TM)s really Gentoo but they futzed with the compiler optimizations then built it in a cluster so they could finish before the heat death of the universe.
Re: (Score:1)
and in other news, when I get out of bed tomorrow I will see this big bright yellow circle in the sky, seems it is always there, every day.
(I had no mod points for you, so had to say something dumb)
Re: (Score:3)
You obviously don't live in the Pacific Northwestern US.
Re: (Score:2)
The other side of the Cascades is still the PNW. And a good part of it is semi-arid desert.
Re: (Score:3)
The other side of the Cascades is still the PNW. And a good part of it is semi-arid desert.
Ha! There’s nothing east of the Cascades. Spokane and Omak are imaginary places - they’re make-believe, just like Narnia or Canada.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Oracle UEK (Score:2)
Instead of CentOS, it would have made more sense to benchmark Oracle Linux, running both the UEK (Unbreakable Enterprise Kernel), and the RHCK (Red Hat-Compatible Kernel).
I've never tried running the UEK on CentOS/RedHat/Scientific Linux. I'm assuming it's built with GCC and runs equally well on AMD vs. Intel.
This is not surprising (Score:3, Insightful)
A hardware company that optimises software to run on its chipsets. No voodoo here. Whilst I dislike Intel for a number of reasons, not the least of which is the recent Minix debacle, this is nothing to ponder over.
I'll stick with FreeBSD and Red Hat/CentOS.
Re: (Score:2)
Re: (Score:3)
I thought perhaps it might be Intel's ICC compiler doing a better job of optimizing for Intel CPUs than GCC does. If that were true, and the distro is compiled with it, then that could explain the performance differences.
But now I doubt that because: (a) what I can find on compiler benchmarks indicates that GCC and ICC are about on par with each other; and (b) Clear Linux has GCC selected as the default anyway.
I wonder if some crucial parts of the system were re-coded to work better on Intel systems, at the
Re: (Score:3)
Um, yeah, optimizing [theinquirer.net], that's what we'll call it. Optimizing [extremetech.com], I like the sound of that.
Re: (Score:2)
Yah, too many have forgotten about those little shenanigans from Chipzilla
Too many forgot that the shenanigans never stopped. The court decision just required them to post an ambiguous unsearchable notice that they might be deliberately disabling optimizations on non-Intel processors.
Re:Why? (Score:5, Insightful)
What we need is a Linux distro that values stability and does not keep pissing around with UIs (and APIs) with no warning.
Ok, I will go back to my BSD cave right now!
Re: (Score:1)
Who give a toss about the speed?
Whomever wants to serve a lot of pages, for instance, without breaking the bank in the process?
Boots faster ... (Score:5, Insightful)
Re:Boots faster ... (Score:5, Funny)
Every time systemd crashes.
Re: Boots faster ... (Score:3)
Re: (Score:2)
Seriously now, for a moment, systemd on Raspbian seems to slash boot time by about half - which is important when you power the Pi on...
Re: (Score:2)
Exactly; Boot time dick measuring is a waste of time and leads to abominations like SystemD.
Re:Boots faster ... (Score:5, Insightful)
But SystemD probably saved you a good 3 minutes over the past 3 years!
He's given that three minutes back - and more - if he's ever needed to check the binary logs SystemD generates.
Re: (Score:2)
You might want to check out journalctl, as apparently you're doing it incredibly wrong.
Re:Boots faster ... (Score:5, Informative)
Re: (Score:1)
But if you can walk away from ms windows and introduce linux in the server room despite the phb, how much easier to walk away from SystemdD
The windows crowd needed somewhere to go and something to do. They've stormed the citadel and the citadel is lost. But on the plus side they've self identified and now we know who they are and where they are and who they're paid by.
Re: (Score:2)
the only itch it legitimately scratched
The only itch of *yours*. Parallel startup is actually the feature many cared about the least and is also why the alternatives saw little adoption.
By the way most people don't give a shit about "concept of Unix", that is something completely incompatible with the workload and interaction between various parts of a modern OS.
Re: (Score:2)
Given that it is the only notable feature beyond looking similar to the solution used in some Unix(TM) distributions I'm curious what features "many" cared about.
"By the way most people don't give a shit about "concept of Unix", that is something completely incompatible with the workload and interaction between various parts of a modern OS."
I work on large enterprise systems moving petabytes of data, tens of thousands of connections per se
Re: (Score:2)
Given that it is the only notable feature
I'm not reading the rest of your comment beyond this as you have just made it clear that you know nothing about systemd much less the problems it set out to solve, how it goes about solving them, and the technical reasons for its very wide spread adoption.
Re: (Score:2)
Re: (Score:2)
I'm not making any argument other than the fact that yours are irrelevant in the face of very big and public technical debates on the adoption of systemd.
Whatever you think is behind it doesn't matter. You're just some voice on the internet and don't represent the adopters, technical committees, or the large user base.
Re: (Score:2)
That is an assertion, not a fact or even an argument, and you provide no logical or factual support for it.
Re: Boots faster ... (Score:1)
Re: (Score:1)
SystemD is either a SysV init replacement or it's not. If it's not then it shouldn't be PID 1; If it IS then it shouldn't be doing all the crap that it currently does.
Re: Boots faster ... (Score:1)
Re:Boots faster ... (Score:5, Interesting)
Re: (Score:2)
Every time I start a new VM on Amazon EC2. Since you're paying by a second now, boot time matters if you're launching hundreds of instances.
If boot time is not a trivial inconsequential amount of time, you are doing VMs wrong.
Re: (Score:2)
Re: Boots faster ... (Score:1)
Re: (Score:3)
Re: Boots faster ... (Score:2)
Re: (Score:2)
Well, it depends which hardware it runs on!
Anyway, at first, it was negligible. But lately, it has started to grow exponentially to produce more and more heat, thus the requirement for its own fans:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Much more now that they built Bitcoin mining into it.
Re: (Score:2)
Not sure why the Royal Automobile Club is involved in this, but I think we see the problem here:
You are using Intel.
If you want uptime, use OpenBSD on Sparc64: you boot once every 6 months - when you upgrade. Other updates don't need a reboot, and you won't have kernel panics.
Re: (Score:2)
Re: (Score:2)
I thought that went out the window when Ross Perot left IBM!
a stripped-down derivative (Score:1)
is faster at cherry-picked benchmarks than its full-sized parent. how much did this ad cost?
Re: (Score:2)
Re: (Score:2)
Perhaps a port from Javascript to C might help.
Re: (Score:2)
This isn't anyone giving more power to enterprise apps. This is a vendor producing something to create the illusion their chips are faster than the other guy. For the record, in the real world, the other guy currently has the better chips both in Enterprise and on the desktop.
Re: (Score:3)
AMD is actually shipping the superior chips ATM and for the first time in at least a decade on the desktop and possibly ever in the Enterprise space. This is Intel throwing out some FUD because THEY took notice of that.
someone doesn't know the meaning of enterprise (Score:2)
Not really earth shattering here... (Score:2)
The car analogy would be a fast motorcycle versus mainstream, general purpose sedans. Yes, Clear Linux is faster. I could possibly make a Linux distro which is faster than RHEL, and other mainstream distros as well, especially if I tossed the initial RAMdisk image, and booted to some sort of init at once.
I appreciate Intel making Clear Linux available, and for IoT devices, a fast boot time is a must... but other than Clear Containers, I'd like to see more security features. IoT is where a focus in securi
Re: (Score:2)
Re: Booting speed! (Score:1)
This old high uptime is good myth just won't die.
True.
We'll file it along with using swap memory is bad
True.
and running everything out of physical ram is betterer.
Depends on what you're doing. Often the file cache lets us use all physical memory usefully without causing the standard issues that 100% memory use might otherwise.
Planned regular reboots are proper maintenance, they catch problems with the boot configuration on the host.
True.
Didn't set that daemon for startup? Forgot to save that static route or
Compare it against Gentoo (Score:5, Interesting)
> but leverages its speed from optimized compiler settings, specially
> built libraries capable of AVX instructions on supported systems,
> a specially tuned kernel configuration, and other optimizations/patches.
I see your "Clear Linux" and raise you Gentoo with
CFLAGS="-O2 -march=native -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"
CXXFLAGS="${CFLAGS}
and also appropriate CPU_FLAGS_X86 for the CPU, as well as the same kernel tuning used for Clear Linux. I dare Phoronix to try that. It should be a much closer horse race.
ClearLinux is basically "enterprise" Gentoo (Score:1)
I love Gentoo and have used it frequently but if you're a sysadmin managing hundreds or thousands of servers on hardware that's not homogenous (different CPUs, different NICs, etc) it's a non starter. Building, testing and distributing multiple builds is a drain on company resources that has to be offset by performance gains. That's a hard sell. There are plenty of companies that use Gentoo but it's generally for very specific functions and not company wide. ClearLinux lets companies get the benefits of
Gentoo users are like Hatchables (Score:2)
Gentoo users are like Hatchanimals. [bestbuy.com] You have to wait for them to emerge to see what you get.
huh (Score:2)
Enter the world of Intel-specific Linux (Score:2)
Stupid benchmarks
Some of the benchmarks run seem pretty stupid, for the goal of evaluating Linux for the enterprise. Whether your Perl script compiles in 0.001 or 0.002 seconds? Really? On others, it had more to do with packages, for example, PHP/5 was slower than PHP/7. That's not really relevant: If you need PHP/7, you'll install it.
That said, Clear Linux does come in ahead on virtually all of the benchmarks listed. Clear Linux is by Intel, and these tests are all running on Intel processors. I suspect th
Re: (Score:2)
I doubt anything is being kept back by Intel, it's just that Intel target a higher common denominator...
Binaries in centos or rhel are compiled for a generic amd64 cpu, and therefore can't take advantage of features present in newer processors. A gentoo install targeting the specific hardware being used to test would probably beat both of them.
This is old news. (Score:2)
Re: (Score:2)
We've know for a LONG time that Intel's compiler can do tricks with x86 that the GCC guys could only dream of.
The major trick is disabling optimizations when the CPU does not report GENUINEINTEL.
So it boots real fast... (Score:4, Insightful)
Who, other than someone running it on a laptop, gives a flying fart how fast it boots?
I've got an older (580 G5) that takes SEVENTY SECONDS before the POST logo appears. I've got HBS (honkin' big servers) that take minutes before it gets to the grub boot. And the servers, we're working on a once-a-month maintenance window, to reboot to new kernels, etc.
Show me how it outperforms other distros running, say, a very large R job, or modeling protein folding. Then I'll be interested....
Re: (Score:2)
I've never seen a VM instance take more than a split second to post. Who* uses servers these days? Throw them off a cliff and into the clouds.
I'm only being partially facetious here. Spinning up an entire OS instance for a short activity is rapidly becoming a thing that we are interested in doing these days, and shaving that boot time counts when you're paying by the second.
Don't benchmark CentOS "out of the box" (Score:2)
Red Hat's "tuned" package will set the CPU frequency governor to a high-performance governor if the word "server" or the word "computenode" appear in the system's CPE identifier. CentOS's CPE contains neither, so a low-performance profile is selected by default.
Details are available here: http://jperrin.org/centos/boos... [jperrin.org]
The short version is that CentOS "out of the box" will always benchmark poorly, and you must run "tuned-adm profile throughput-performance" to get a high performance profile.