Ubuntu Linux Evaluating x86-64-v3 Based Build - AVX & Newer Intel/AMD CPUs

[coder]

And what exactly are they doing this time?

I was responding to CommunityMember 's assertion that only paying customers matter to Canonical.

Did you even read their blog post?

Yes, I know it's just a trial. I was referring to the hypothetical scenario where they move ahead with v3 as their new baseline.

[ms178]

Oh, but see that pesky word "also"? Doesn't that tell you it's not the main point? Again, a distro can target any -march level it wants to -- it always could! ISA feature levels were never needed just as a baseline build target.

I have never claimed the creation of new baselines to be the main point of the feature level introduction. But you really love to misrepresent other people's statements, to fight a straw man argument. I've already told you that doesn't work with someone like me, you keep trying though.

Quoting your former post, you falsely stated that "The whole point of glibc defining those feature levels was specifically to support hwcaps" which I falsified with the quotes of Florian, that prove that the hw caps support was just one of several issues addressed with their introduction. The shaping of new base lines for distros was also a clearly stated goal as the quotes have proven to you. What's even worse is that you keep misrepresenting that fact over and over again, even when presented with the original post of the creator himself. So much for the reality you live in and a facts-based discussion. All you want is to be right or to keep winning. I think everyone still interested in our personal feud might get the idea by now how you simply twist reality to your liking.

And I'll continue to point out these flaws in your comments in the future. As a funny aside, calling me arrogant, but coosing "coder" as a nickname to distinct himself over others, is yet another example of you not holding up to your own standards. If you don't like to have x86-64-v3 as a new base line, fine. I did get that long ago, by the way. But please don't spread misinformation or derogate others who disagree with you, that's not helpful.

pepoluan Coder just likes to fight imaginary fights and articulates his own opinions here, rooting for a glibc hwcaps-based solution that comes with downsides of its own that he ignores to acknowledge.

[TXTad]

In other words, things that won't be running Ubuntu Server...

On the contrary, that is exactly the sort of machine that is running Ubuntu Server for a lot of folks. My company has hundreds of customer sites, each running a little, inexpensive mini-PC and a current version of Ubuntu Server. Our oldest still-running machine has been running continuously since 2008, and has been updated periodically along the way.

[uxmkt]

x86_64 is such an epic mess [thanks to Intel messing up product stacks]

Well, the x86 base was a mess to begin with (hi Intel), and there is only so much lipstick AMD could put on a pig ;-)

[edwaleni]

Does this mean a "Clear Linux - Ubuntu Edition" is in our future?

(or should I say Ubuntu Server - Clear Edition")

[drakonas777]

Of course the most rational solution is to force all mainstream distros keep using ancient level, because we have 3 linux fanatics who use atom-based systems (mostly for ssh and vim). Of course.

[coder]

Of course the most rational solution is to force all mainstream distros keep using ancient level, because we have 3 linux fanatics who use atom-based systems (mostly for ssh and vim). Of course.

As I said above, the hwcaps-based approach not only delivers nearly the same gains as moving the baseline, but also gives people with v4-capable CPUs the added benefit of exploiting more of their CPUs' capabilities.

Yes, there's some infrastructure work needed to support building & packaging of multiple ISA levels, but most of the hard work is already done. Although certain individuals have decided Ubuntu should salve this by maintaining multiple complete distros at v3 and v4, I'm not aware of that option being on the table. Plus, if Ubuntu were going to do that, then why not just go ahead and maintain a v1 or v2 distro, as well? I think it doesn't make sense to have entirely separate distros, when only a minority of packages really stand to benefit.

[coder]

On the contrary, that is exactly the sort of machine that is running Ubuntu Server for a lot of folks. My company has hundreds of customer sites, each running a little, inexpensive mini-PC and a current version of Ubuntu Server. Our oldest still-running machine has been running continuously since 2008, and has been updated periodically along the way.

Yes, that's exactly what I'm talking about.

ms178 wants to force your company to switch distros or replace all of that customer hardware, just for the sake of unproven wins on a few binaries with the vector code compiled directly in that don't already have runtime dispatch (as anything with hand-coded SIMD already does).

[carewolf]

I remember exactly nothing alarming or abhorrent from the era. Afaik it worked seamlessly for the user.

Maybe you could be more condescending and explain your attitude for those of us who didn't quite use the feature.

It requires adaptations in the build system but often also in source files as it requires two versions of every linked object file. So if you have arm-specific code in a single source file you can not link it into a fat binary as the object doesn't exist in an x64 version. The work around is not to have arch specific sources or add an additional relinking step to hide the extra object files. Note this problem is entirely created by the Apple developed tools being stupid and inflexible, but being stupid and inflexible is how Apple writes sofware.

[avis]

It requires adaptations in the build system but often also in source files as it requires two versions of every linked object file. So if you have arm-specific code in a single source file you can not link it into a fat binary as the object doesn't exist in an x64 version. The work around is not to have arch specific sources or add an additional relinking step to hide the extra object files. Note this problem is entirely created by the Apple developed tools being stupid and inflexible, but being stupid and inflexible is how Apple writes sofware.

This sounds like Linux developers could totally create something more usable/universal/hassle-free.