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.

Comments

Does it use

[Anonymous Coward]

Systemd? Hopefully they chuck it.

Re:Does it use

[tlhIngan]

There's one thing about systemd that I don't understand: If it is terrible (and I have no doubt that it is, from its philosophy to its implementation), why have almost all of the major Linux distributions moved to it?

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.

Function multi-versioning.

[Ungrounded Lightning]

Upon seeing the description of function multi-versioning I thought of three distinct ways to use that for malware in as many minutes, and the ideas are still coming. (And I don't write malware, so someone in the field would probably think of more, faster,)

It's also a great way to make competitors' processors look bad: Detect their processors and fall back on the minimalist defaults or even hand them "grinched" code that does worse, or contains odd kickers. Or just don't support THEIR accelerations. Also: Don't support their implementations of YOUR accelerations.

Kind of a silly summary;

[hey!]

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.

Re:Different compiler

[Anonymous Coward]

A few years back, GCC took out all the processor-specific optimizations and put in only general purpose optimizations

WTF are you talking about? That is patently false.

Re:Different compiler

[Anonymous Coward]

Clear Linux also comes packaged with spyware

From the 1st paragraph at that link:

The end users may disable the telemetry component of Clear Linux OS for Intel Architecture or even redirect where records go if they wish to collect for themselves.

Not the point. Telemetry collection should be opt-in, not opt-out.

Bullshit, and more bullshit.

[s.petry]

The only person using false drama is you. I never stated that it was an evil plot, you did that. You also attempted to claim I said it, which is bullshit.

Telemetry requires a consumer dig through details to find it, and to turn it off. How hard is it to do like Redhat does, and give a prompt to users during the install which asks them if they want the service on or off? Don't bother stopping to think about why Redhat does this as opposed to just turning it on, because that may be more "false drama".

You claim to agree with my position, but then type what a shill would type. It is obvious why _you_ remain hidden in anonymity and the person who is fighting for anonymity does not hide.