Slashdot Mirror
Intel's Clear Linux Distribution Offers Fast Out-Of-The-Box Performance (phoronix.com)
An anonymous reader writes: In a 10-way Linux distribution battle including OpenSUSE, Debian, Ubuntu, Fedora, and others, one of the fastest out-of-the-box performers was a surprising contender: Intel's Clear Linux Project that's still in its infancy. Clear Linux ships in an optimized form for delivering best performance on x86 hardware with enabling many compiler optimizations by default, highly-tuned software bundles, function multi-versioning for the most performant code functions based upon CPU, AutoFDO for automated feedback-direct optimizations and other performance-driven features. Clear Linux is a rolling-release-inspired distribution that issues new versions a few times a day and is up to version 5700.
Intel's own compiler in many cases generated code that runs 15%-20% faster than code compiled under GCC.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Linux 10?
Clear Linux is a rolling-release-inspired distribution that issues new versions a few times a day and is up to version 5700.
Big deal. Firefox will catch up with that shortly.
It must have been something you assimilated. . . .
Its nice to see this however we really should, in general, have a better way for Linux programs to be able to easily take advantage of the CPU extensions available without recompile. There are dozens of permutations of CPU extensions, so distributing a binary for each permutation is not feasible. Full from source compilation takes too long for many users. Having Linux binaries being able to use the CPUs most advanced features has been a problem. One solution that I favor is to take a page from AS/400, in a variation of that, in each library file, put a copy of the machine code, but also a copy of the abstract syntax tree, the last compilation phase. If the binary is moved to a new CPU, the AST is run through the code generator to regenerate the machine code in the file according to the options the CPU supports. All done in situ. This is much better than storing a copy a binary for each CPU permutation in a library file. It makes things easy to use and is faster than compiling from source as the lexer and parser phase does not need to be repeated.
The rankings in individual benchmarks were all over the place; a composite of those benchmarks is only valid for some theoretical "average" workload that's the average of all the workloads each individual benchmark is supposed to represent; almost nobody is bound to have a workload that resembles that "average".
In fact the whole "shooutout" scenario is silly because Clear Linux is a container-centric distro. It makes no sense at all to compare it to general purpose distros like Ubuntu and plain vanilla Centos then leave out Red Hat/Centos's Atomic Host flavors.
In any case if performance is your paramount concern, then "out-of-the-box" performance is bound to be irrelevant to you because you'll be compiling from source with your own choice of compiler and flags, as well as fiddling with all those bells and whistles exposed in the /sys interface. What's interesting would be an exploration of why various distros did better or worse on individual benchmarks.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
To me, an extra 0.1% performance increase, even if I am only imagining it to be faster, is certainly worth one day a week recompiling all of the latest packages from source code.
If 1 part in 1000 runtime improvement is worth 1/7 of one machine's time, then you must be running a cluster of at least 142 identical servers.
No matter what distro I use for my desktop, I always use the latest pf-kernel, with bfq scheduler, low latency, cpu optimizations, etc. I can overload the desktop, and music/video is smooth as silk, and compiling is faster. Its a real world performance boost.
I'd love to see how a pf-kernel does vs stock on each distro.
Because maybe it isn't as terrible as it seems?
Sure, there's a lot of NEW things in it, but isn't Linux all about new? And things are different, which gets people tied up in knots.
And the other thing is, people don't realize the shortcomings of the ever-popular SysVInit - I mean, why do we emulate in SysVInit, init? Init is a daemon manager - in practically all Linux distros, it's managing getty (which spawns login). And when you end your session getty dies, and init duly restarts it, like a good daemon manager does. And you can have daemons kill and restart based on runlevel. This is built in, standard default behavior of init. Yet everyone creates elaborate scripts that do the same thing, or even programs that spawn a child that does the service, and when it crashes or dies, it respawns it. Something init already does. Init even does rate limiting - if a daemon quits too quickly, init stops starting it for a few minutes.
SystemD formalizes this as a fundamental part of the system - init really should manage daemons, not a rough collection of shell scripts that try to mimic its behavior.
Granted, things are more complex, like how PulseAudio made audio more complicated. But then you realize that audio IS complicated these days, especially on a desktop OS. There was a time you could open /dev/dsp and that's it, but those days are long gone, because users have multiple audio devices and not only that, but those audio devices can change suddenly. And no, the hardware can change - perhaps they're listening on wireless headphones through Bluetooth, but then they want to switch to speakers which require switching the underlying hardware, and so forth.
And initialization and startup is similar.
In the end, what's happening to Linux is what Android did to Linux. Android has its own init system (init manages daemons, like it should), its own graphical system, its own audio layer and much more.
And it was done because the demands of mobile make it purposely complex and consumer expectations ensure it isn't easy.