Other Linux Distributions Begin Analyzing Clear Linux's Performance Optimizations

[pal666]

isn't it nice that several people replied to my comment in this thread which is now gone along with two others?

[airlied]

Interesting and slightly misinformed... I wish they'd talk to the Clear Linux team directly...

Claiming that the clear containers kernel is extremely heavily patches is .. slightly dishonest. there's 24 patches (including security), most are very minor (both in size and in boot-time impact). The Fedora 24 kernel (snapshot) has 67 patches in it!! Distros patch kernels, usually in minor ways... calling out another distro for heavy patching when your own distro kernel has 2.5x the number of patches... shrug.

The question isn't the amount of patches to carry, it's where they came from and where they are headed. If you examine the Fedora patches they are nearly always stable backports that haven't gotten to stable yet, or changing configurations that upstream defaults to something different. They rarely hack into core kernel code. So I think you are being a bit disingenuous here. Calling out a distro for heavy patching of stuff badly, and with no intent or upstreaming the hacks in their current form is a lot different, than calling out a distro who packages the latest kernel with some additional stable patches that are already upstream and haven't made their way back through the upstream process yet.

I've no idea what the Clear Linux patches are doing, but if they aren't all submitted upstream, then you guys suck, if they are yay for everyone.

Dave.

[Michael]

If the process of "commenting out" the unused code is performed automatically by a compiler (it can be a JIT compiler), it's a valid approach. Otherwise it is questionable.

I am not sure what kind of "commenting out the code" we are talking about here. Can somebody clarify this please?

I don't have any Intel Chromebooks

[arjan_intel]

The question isn't the amount of patches to carry, it's where they came from and where they are headed. If you examine the Fedora patches they are nearly always stable backports that haven't gotten to stable yet, or changing configurations that upstream defaults to something different. They rarely hack into core kernel code. So I think you are being a bit disingenuous here. Calling out a distro for heavy patching of stuff badly, and with no intent or upstreaming the hacks in their current form is a lot different, than calling out a distro who packages the latest kernel with some additional stable patches that are already upstream and haven't made their way back through the upstream process yet.

I've no idea what the Clear Linux patches are doing, but if they aren't all submitted upstream, then you guys suck, if they are yay for everyone.

Dave.

The amount of "real" patches is very small, and the most impactful in terms of code are "cpu init sucks in linux, in a VM we can do faster since its fake hardware", which Thomas Gleixner is currently rewriting based on "hey we need this better" discussions we've been having for some time. The patches "as is" won't go upstream, because upstream is fixing the same thing in a better way; I'm fine with that (and reviewing the upstream code etc etc).

We have no intent to carry long term "real" patches, that's what upstream is for. (the "real" part relates to your "changing some defaults", all distros do that, and so do we, and I'm totally fine with that; the defaults a specific distro might pick aren't per say suitable for a more generic upstream.. I don't consider those "real" patches).

[arjan_intel]

If the process of "commenting out" the unused code is performed automatically by a compiler (it can be a JIT compiler), it's a valid approach. Otherwise it is questionable.

I am not sure what kind of "commenting out the code" we are talking about here. Can somebody clarify this please?

specifically we commented out some code in the CPU initialization code that is not needed for running in virtual machines, but which is expensive.
The upstream developer-owner of this code is currently in the middle of restructuring this code so that our patch won't be needed in the future.

it's easy to look at a patch and call "foul you don't play by our rules", but it'd have been nice if the story behind the patch was asked about before calling foul....

[liam]

benchmarks with AMDcripple
I will never buy an Intel product in my life if I can help it, the company is very scummy.

Companies, as entities, exist on paper. People are scummy. People run companies and can have people under the company aegis be involved in scummy things. Once those scummy people are gone, the company is run according to whoever next sets policy.
Please, let's not literally buy into the idea that "corporations are people"

[unixfan2001]

Actually clueless. I don't care much for intel, mostly cus unfair prices. I don't use AMD cus their cpus are weaker (even if intel has that amdcripple thing in their compiler), I'm one of the people waiting for zen in hopes of fair pricing unlike that intel overpriced shit.

Do you have actual, empirical evidence that Intel hardware is overpriced or priced "unfairly"?
The fact that AMD CPUs cost the same as a slightly luxurious breakfast doesn't make them fairly priced, nor does it make more expensive Intel CPUs unfairly priced.

Somehow I suspect when people say something is unfairly priced what they often really allude to is their own cheapskateness.

[unixfan2001]

It's not a conspiracy theory if they got sued for it and AMD won in a court of law...
The FTC even investigated it.

https://www.ftc.gov/os/adjpro/d9341/091216intelcmpt.pdf

Wrong! The court of public opinion doesn't validate scientific findings.
Seralini won a defamation suit too. That doesn't make GMO unsafe either.

Court of law < peer reviewed science

[haplo602]

The solution you are mentioning will fail when a Linux user downgrades the CPU in the machine, or moves the disk to another machine with a different CPU.

In my opinion, Intel's solution - to have both the normal AMD64-compiled libraries and the AVX/AVX2-compiled libraries installed on the machine at the same time - is the right one.

hmm

Both situation you describe are easily solved with a livecd and distro update. Which you'd do anyway when changing architectures because I doubt you will keep the optimized libraries for other than your own system. If you don't, then you don't care about the optimizations and don't need the bloat in the first place.

also moving the disk to another machine can be done only for 2 purposes:

1. forensics - here you will not likely run the OS/programs itself
2. recovery - already described ...

[starshipeleven]

Do you have actual, empirical evidence that Intel hardware is overpriced or priced "unfairly"?

Going on a limb here, and I'm going to say that his "overpriced" is comparing the new CPUs with the CPUs of a year or two past.

No major changes in overall CPU power (for desktops), the 2-year-old CPUs cost less due to clearance discounts and similar.

But it is a bit of a stretch, they cannot really cut prices by a massive amount like AMD did (selling at a loss).

Intel pricing hasn't balooned that much, considering that newer processes aren't getting cheaper. (if we exclude the i7U lines, also called "rebranded mobile i3 costing twice as much")