Glibc sysdeps: dl_platform detection effectively performs “cripple AMD” | Hacker News Reader

Glibc sysdeps: dl_platform detection effectively performs “cripple AMD”

sourceware.org

217 pointsarthur2e597 comments

The point is to put Haswell-optimized code in the "haswell" subdirectory. However, compiling code with -march=haswell (implying -mtune=haswell) does a lot of other platform/manufacturer-specific optimizations as well (not just usage of the various extensions), like favoring instructions X that perform slightly better over other instructions Y, even if instructions X would be significantly slower on AMD processors.

So it does not seem 100% certain, at least without testing, that using "haswell" on AMD would be beneficial (it depends on whether the speed-up from extra extensions offsets possible speed loss due to other Intel-specific optimization). And Intel was probably not going to do such testing.

But my guess is that using the "haswell" libraries on AMD will be beneficial, and the check will probably be loosened accordingly in the future.

Note, though, that the feature checks currently performed do not seem exhaustive, so I don't think one can simply remove the Intel check as-is. Haswell has a lot more extensions than the ones currently checked.

I'm not sure it is even worth it to distinguish by CPU model. My hunch is that the optimizations the compiler does for a specific model are vastly overshadowed by the gains of having certain extensions available at all. So glibc should only distinguish by avx512, sse4.2, etc. usually a CPU that has a newer extension available also has all of the older ones, the question is how many exceptions would arise, and what the speed penalty would be to fall back to the next slower implementation.

Putting aside most of your earlier comment,

> the question is how many exceptions would arise, and what the speed penalty would be to fall back to the next slower implementation.

This can be done for essentially free with ifuncs.

Here's a crummy example from the GCC docs: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.ht...

Here's a more thorough and (IMO) intelligible treatise on the subject: https://lwn.net/Articles/691932/

The FMV (4.8) and clone (6.0) features are intended to be easier-to-use wrappers around ifunc. FMV-4.8 (C++) generates the ifunc dispatching code for the programmer, and FMV-6.0 (C/C++) moves on to do the code duplication for the programmer too. It is added with the assumption that GCC's optimization / vectorization magic is good enough to gain significant performance gains by just changing -march options on the exact same piece of code.

A good way for the lazy person (me) to find out what processors have what instructions is simply dig in the GCC source code and see what their enormous tables have to say.

  For Zen since 2017 (znver1): https://github.com/gcc-mirror/gcc/blob/44e419819c4076843d0c92dc6913821a016a8519/gcc/common/config/i386/i386-common.c#L1673-L1681
  For Haswell (haswell): https://github.com/gcc-mirror/gcc/blob/b2903606a95ff609a65abe7ac0cbf4321ad2614d/gcc/config/i386/i386.h#L2372-L2382

If you collect all these entries and do some set operations on them, it should boil down to znver1 having a bunch of extra things compared to haswell {"SSE4A", "ABM", "PRFCHW", "MWAITX", "ADX", "RDSEED", "CLZERO", "CLFLUSHOPT", "XSAVEC", "XSAVES", "SHA"} and haswell only having a HLE (Hardware Lock Elision) extra. HLE is designed to be fully backward-compatible, so yes GCC Haswell code will work on Ryzen with no illegal instructions.

With these very textual and probably super easy-to-parse bitset data, you should also be able to answer the "what previous things are missing" question as well. You should be able to see some historical divides with ssse3/sse4a and fma3/4 et al.

* * *

About the completeness of the check: trust me it is complete enough to only include all extant processors that are supersets of Haswell. POPCNT plus AVX2 narrows it down a quite lot.

The implementations of extensions on different CPU microarchitectures can vary quite a bit from the same vendor. And performance of those extensions can vary by an order of magnitude between CPU vendors, sometimes because vendors will initially add CPU extensions as microcode if they did not design the extension themselves. AMD has microcoded many Intel extensions in some of their architectures for binary compatibility but without performance benefits, and many of their native implementations behave differently in material ways for optimization. The existence of the feature does not imply you should use it for highly optimized code, it may be slower than software versions of the same thing, or that you should use the feature in the same way to optimize code.

It is quite complicated. The AMD and Intel microarchitectures are different enough in design that some low-level optimizations around many extensions really don't translate well between them. The differences can be big enough that you take them into account at the C++ level too, writing target-specific code.

Individual CPU vendors are in the best position to provide software optimization for specific implementations of their microarchitectures. Unfortunately, AMD invests relatively little in this and relies on the open source community to fill in these gaps whereas Intel is excellent at providing first-party software optimization support for their CPUs.

Although you probably overestimate a bit the impact of uarch diff between haswell and zen, there is some truth in theory in what you said. In practice, zen is quite close to Skylake in terms of general uarch principles and main figures, and zenv2 even more so (or even better). IIRC for ZenV1 AVX2 should yield no gain compared to AVX, though.

glibc is not Intel's project and is expected to have a minimum amount of neutrality in own it is maintained -- that also includes how patches are accepted or modifications are asked before they are integrated.

The dispatching is probably to implement things like memset & memcpy etc, which are easy to benchmark, and it is probable that the haswell version will at least be better than whatever is used right now with an amd zen (and even more probable for zenv2). Optimizing further can come later, if anybody wants to do it.

Therefore, I think this ticket is justified (but I also think that this is not a drama that is has not be taken care of sooner)

Thanks for the insight, last time I remember writing assembly for speed was probably the early sse days.

Sounds like a great benchmarking rabbit hole to go down though. :-)

I don't know, the vector units vary a huge amount. Let's say you have an AMD chip with AVX2.

For Excavator you have something like 2x128 adders and 2x128 multipliers, split over two cores.

For Zen 1 you have 2x128 adders and 2x128 multipliers per core.

For Zen 2 you have 2x256 adders and 2x256 multipliers per core.

And you can combine an adder and a multiplier to do FMA.

And for Intel chips you generally have 2x256 units that can do add or multiply or FMA.

There are a lot of workloads where you want very different strategies across these architectures.

Hm, is this really "crippling" AMD? Seems more like Intel submitted a performance patch that is only enabled for Intel processors, but could be extended to support AMD too.

There's a moral difference. It is wrong to intentionally degrade the performance of your competitors. It is not wrong to not do something that benefits others.

> It is not wrong to not do something that benefits others.

The patch however sneakily removes the chance that the features existing and working on the competing processors are properly detected and used.

In free software it’s clearly evil.

So patch it. That's the point of free software: the freedom to modify it to your needs.

Well the patch certainly met Intel's needs (a nice little performance bump over its ascendant rival) ... and since someone with a keen eye spotted it, now the rest of us can submit a patch to correct that. But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.

> But I'm not sure that a back-and-forth war of self-serving patches is very productive or serves anyone very well.

In large FOSS projects you have enough eyes on those patches to ensure they actually converge towards some (unbiased) optimum.

That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?

about 3 months ago, in a code audit.

In this scenario, is not each self-serving patch strictly an improvement? It's at least arguable that a back-and-forth competition to provide improvements serves everyone well.

This is why a bug is reported, when it is patched, the bug will be closed. This is the point of a bug tracker in a free software project: document the current issues that need to be solved or improved.

> The patch however sneakily removes the chance ...

If they haven't tested on other processors, should they leave code in because it has a "chance" to work on something else? I think both sides of this question could be legitimately argued so I wouldn't jump to calling it "evil".

What do you mean `"chance" to work`? If the CPU claims to support an instruction, it's perfectly fine to treat it as supporting the instruction.

The point is that the correct way of doing this is to check for the feature not for the vendor. It's perfectly legitimate for Intel to submit code that helps Intel CPUs, but glibc shouldn't be accepting code that unnecessarily favours one CPU vendor. The correct version of this code would just check for the feature rather, so that if AMD does support this it just works.

> but glibc shouldn't be accepting code that unnecessarily favours one CPU vendor.

why ? AMD just has to do the same. I want to be able to use the CPU I buy to its maximum capability.

The key here is 'unnecessarily'. If it it works just as well on an AMD CPU it should be enabled on an AMD CPU regardless of who submitted it.

but it is to AMD engineers's job or at least people willing to run benchmarks on AMD cpus, to ensure that "it works just as well on an AMD CPU", not to Intel.

No.

With an open source project like this, every contributor has a responsibility towards all users of that code. That means that if Intel makes a change, they are also responsible for AMD support. Putting a generic optimization behind a vendor detection is not acceptable in the community.

However, as others' have mentioned, this previously might not have benefited AMD, despite technically being supported, so it was likely meant well at the time of implementation. Intel is usually quite good players when it comes to open source contributions.

They didn't harm in any way the AMD users, just didn't invest in their well being. You can't expect intel to benchmark if a feature would be better or not on amd, that's not its role. It submitted a patch that was good for its users. Up to amd to benchmark it for their users. It would still be a lot less expensive to benchmark it and enable it for amd, than develop it from scratch as intel.

That's true. Whoever accepted the patches should have thought of that. But that happens, right? I don't think this is newsworthy at all.

Bad implementations happen, people find better ways, they refactor and improve things. This holy war some people want to have between AMD and Intel is quite boring.

> You can't expect intel to benchmark if a feature would be better or not on amd, that's not its role.

Why not? If I was maintainer I wouldn't accept the patch, I'd ask the authors to test on AMD as well. Intel is well funded and glibc is not their project. If they want glibc to include optimizations for their platform they can do the minimal level of effort to see if it can be enabled on AMD as well.

Historically Intel has been found to create suboptimal code paths in its own compiler, in addition to not enabling features supported on competitor's platform, in its own compiler.

What happens if the implementation is slower but still works on AMD? Is Intel responsible for also performance testing and determining if/when to disable an implementation on a given chip? You're putting a lot of burden on Intel to do extensive testing and also not protecting them from criticism if a change is suboptimal for a competitor.

I think it's fine to submit a patch that's known to be good for a subset of CPUs and perhaps it should be tagged for another maintainer (e.g. AMD) to review and contribute to as well.

If the original patch contained a benchmark showing that it was slower on the current AMD processors then this would be a reasonable argument.

It did not, because no such testing was done.

I think there's a pretty low baseline of effort they can put in. I also think that if they enabled new code paths for newer instructions that turned out to be slower on AMD, very few people would claim this was Intel being evil. Most would blame AMD for selling a defective product.

I would argue it's absurd ask for Intel to maintain test platforms for a competitor.

At best you could ask them to flag platform specific code in such a way that others, who are better equipped, can test against other platforms.

And then, after said minimal amount of effort, it turns out that the patch actually hurts performance on some AMD CPUs, and people bring out pitchforks for Intel intentionally slowing down AMD?

It seems to me that the current approach is the most conservative: limit the impact to what you know best. Leave it to the experts of the other system to do whatever is needed.

I don't understand your scenario. The minimal amount of effort includes a benchmark, so it wouldn't be enabled if it hurt performance.

How many AMD CPU configurations exist? Does a minimal effort require regression testing all of them? On how many benchmarks? How do you know that there aren’t untested potholes in AMD CPUs that you may not be aware of?

In the end, the result of this feature is a performance improvement for some and status quo (no perf regression) for everybody else. It’s a net benefit with no downside in absolute terms.

In addition, it provides a free roadmap for AMD or its users on how to get the same benefit as well.

The potential backlash of enabling this for AMD as well by somebody of Intel (“active sabotage!!!”) is much larger than this tempest in a teacup where AMD is currently missing out on something.

The same benchmarks you used to justify adding it in the first place, on their current model and ideally a slightly older one, would be sufficient.

> The potential backlash of enabling this for AMD as well by somebody of Intel (“active sabotage!!!”) is much larger than this tempest in a teacup where AMD is currently missing out on something.

I disagree.

> You can't expect intel to benchmark if a feature would be better or not on amd, that's not its role.

It is, in facts, its role as a major contributor.

And they do, in fact, benchmark and fix AMD as part of its open source efforts, as they should. Case in point: https://github.com/OpenVisualCloud/SVT-VP9/pull/48 (Intel developer contributing AVX2 improvements, specifically mentioned as AMD Epyc improvements).

They can cater only to their own devices when the code only applies to those devices (e.g. the i915 graphics driver). In generic code paths, they must cater to all users. Adding optimization using generic features that have generic flags, but hiding them behind vendor detection, is borderline malicious. The developers here are well aware that there is a feature flag they should check instead.

> With an open source project like this, every contributor has a responsibility towards all users of that code.

What ? no. Do IBM engineers have responsibility towards Qualcomm engineers when they commit IBM patches under IBM-named flags to the linux kernel ? What happens if there's a new CPU company in two years that would also happen to work fine with these flags ?

> Do IBM engineers have responsibility towards Qualcomm engineers

Yes, in every way. However, with Qualcomm not having any PowerPC architectures, there isn't much harm that could be done. And for reference, Intel also tests AMD as they should, and even submits performance improvements for AMD as they should.

But this is quite bad: Instead of: `if (supports(generic_feature)) { do_with_generic_feature(); } else { slow_approach(); }`, they did `if (intel_haswell) { do_with_generic_feature(); } else { slow_approach(); }`.

The only time where that is acceptable from as big a contributor as Intel, is if they tested and concluded that other CPUs were actually slower using this feature.

> What happens if there's a new CPU company in two years that would also happen to work fine with these flags ?

That is exactly why the feature flags exist in this generic code! You can query what instruction sets are available on the CPU. Vendor-specific code should only be added to deal with product-specific defect.

The glibc core maintainers have such responsibility, yes, but it's too much burden for occasional contributors focusing on a single issue or a particular architecture. Setting the bar too high would make glibc lose valuable patches from both Intel and AMD.

A reasonable compromise is requiring architecture-specific contributions to at least do no harm to other vendors, and to not increase maintenance costs for core developers by duplicating code.

In this light, AMD engineers wanting to enable the haswell optimizations for their processors would be asked to share the existing code rather than copy-paste it. Intel engineers would participate in the public review to ensure AMD patches don't cause regressions for Haswell. If they have contributed testcases, they will demand that AMD patches pass them on all supported architectures before being merged.

This is pretty standard in all open source projects with multiple stakeholders.

> occasional contributors

Intel has made 171 contributions in form of commits to glibc as of master today. I doubt they can be considered an "occasional contributor".

And even then, small contributions only get to bypass the responsibility if we're dealing with small bugfixes.

If intel is intentionally checking based on vendor rather than feature, that is scummy. Glibc should not accept patches that do this check. Instead requiring such checks to be based on feature detection.

Yes, and that's what is happening with this glibc improvement. glibc is part of the C runtime; it is part of what makes C run on a given CPU.

What are you complaining about, exactly? The system is working as it ought to work.

Since AMD has equally no obligation to Intel users, they can submit a patch that replaces Intel's

    if (intel)
        fast();
    else
        slow();

with

    if (amd)
        fast();
    else
        slow();

Or maybe there's a better way.

While I completely agree with the principle, there may be practical issues for the glibc maintainers. Suppose, for example, that the use of the feature in a given way is an optimal solution on Intel processors but not on AMD? In that case, releasing the code might also be seen by some as enabling a campaign by Intel against AMD. If the glibc project does not have the resources to check, perhaps the best option is to start with a conjunction of feature and vendor checks, with the latter being expanded to include all vendors that have endorsed the change.

It might just be the easiest way to do it. It's also possible that Intel didn't have access to samples of enough AMD stuff to test, or the wrong department had it, or they couldn't get approval to take the time it would require. The GCC guys almost certainly lacked the hardware, time, and inclination to do this instead. It's not malice, I don't think, so much as practicality. I'm sure they'd accept an AMD patch enabling this where available.

> Intel didn't have access to samples of enough AMD stuff, or the wrong department had it, or they couldn't get approval to take the time it would require

I seriously doubt that.

You'd be surprised how bad communication can be in a big company the size of intel. I'm sure they have plenty of samples of AMD stuff, but I could believe they're being used mostly by some cpu-testing division, rather than the open-source one.

I wouldn't be surprised that communications were bad within Intel. I also wouldn't be surprised if there was zero political will to make sure their contribution worked properly on AMD processors. Combine the two and you get whatever plausible deniability you want to use to deflect the argument, I suppose.

Intel and AMD should provide GCC maintainers hardware. It could easily come out of the marketing budget, because benchmarks compiled using gcc would be affected, and they use benchmark numbers in advertising.

The optimization could be a slowdown on other chips. AMD uses narrower vectors then Intel for one.

While this patch from @intel.com looks bad i wonder what has AMD been doing in the meantime? Atleast intel appears to have someone looking at Glibc performance.

Intel’s software division is bigger the the whole AMD.

Could this be a legitimate unintended consequence of the pull request or some new dirty pool tactic?

Either way I agree with Mingye Wang's assessment, this kind of thing cannot be allowed to get into the source tree.

Hopefully AMD will increase their Linux activities with their new bigger market share and income.

Wait, where in glibc is SIMD used anyway?

I know that it is used at least for the implementation of functions like memcpy.

All string functions: not surprising since recent processors have the crazy PCMPxSTRy instructions that are basically a hardware implementation of strcmp, strchr, memchr, strspn etc.

memcpy and memset use SSE on some generations, but these days are best inlined by the compiler as "rep movsb/stosb".

I better hope AVX512 isn’t used on simple string functions, as it causes so much heat Intel CPUs have to reduce their clock speed significantly, affecting other running processes as well.

https://www.tcm.phy.cam.ac.uk/~mjr/IT/clocks.html

There’s nothing wrong with dropping the clock speed when the whole point of SIMD instructions is that they execute on multiple data. As long as the clock speed drop beats the multiplicative speedup from doing 4x/8x/whatever operations in parallel, it’s fine

My point is that the clock speed is also dropped for other processes. So it's not a simple heuristic "oh if we have more data than X we can use AVX512 instead of AVX256", because you do not know what other processes are doing, and they will be slowed down as well.

This type of heuristic only works if you are the sole users of the server, e.g. a database server.

The problem is that the architecture in question would take forever in cpu time terms to switch back and forth, so a sprinkle of heavy avx512 was the worst of all worlds. In addition, some cpus would emulate 512 with half width micro-ops during voltage ramp up. Yes, it sounds crazy.

Not it is not fine at all. If you have too many instructions but not enough, your whole CPU will run slower mostly on non AVX-512 instructions, and maybe even your whole package => the end result will just be slower. Not to say that those processors are bad, but AVX-512 on them is for niche workloads.

> it causes so much heat Intel CPUs have to reduce their clock speed significantly,

How about: don't buy affected CPUs if you care. The last thing people who write libraries should care about is a few selected CPUs that underperform on a generally useful feature.

Nope. At this point given the state of the market, and given what AVX512 does to begin with (so maybe the "at this point" will be for forever), it makes very very little sense to use it everywhere. It would just be actively detrimental to most users.

The instruction and instruction set referenced in the comment you're referring to (PCMPxSTRy and SSE) are not AVX512; they were introduced long before AVX512 chips were manufactured.

> memcpy and memset use SSE on some generations, but these days are best inlined by the compiler as "rep movsb/stosb".

Why? I’ve usually seen this get compiled to some version of “mov byte ptr, inc”.

You want to copy more one byte at a time (unrolling by 4, 8 or more; and for memset, multiplying the stored value by 0x01010101...). In recent processors rep movsb and rep stosb do all that in microcode, and are also able to copy or fill the destination one cache line at a time.

For example strlen: https://stackoverflow.com/questions/57650895/why-does-glibcs...

That's not a very good example; this code is generic (although non portable) C optimized implementation, not something making use of fancy processor instructions. It is even less probable that the compiler understand it and manage to optimize it to using dedicated instructions, when it is written that way.

Compilers do autovectorization (with varying degrees of success) so potentially in lots of places?

This is about the library not the compiler.

A library is compiled with a compiler.

This check is the opposite of compiler autovectorisation. Its point is specifically for the library to dispatch between implementations (e.g. to an explicitly vectorised one)

Yes, and it can make sense to dispatch between compiler-vectorised and non-simd implementations.

It does make sense, the issue at hand is how it's done: by checking for the CPU vendor / product line rather than asking the CPU if it has the operations we want.

Yep - capabilities based switching makes most sense when you are just interested on what code can successfully execute, and not making decisions based on known perf characteristics of microarchitectures.

But this subthread was about "where in glibc is SIMD used anyway?" and the answer is that in all code, potentially.

Re-reading this, check is orthogonal to autovectorisation. Opposite of autovectorisation would be manually written SIMD assembly / intrisics code.

Read the bug again! The feature is about "transparently" loading libraries that are put in specific subdirectories based on the CPU so that a single configuration can work fast everywhere. Intel's Clear Linux wrote about that in https://clearlinux.org/news-blogs/transparent-use-library-pa....

While it might appear scammy AMD lacks instructions on some of its pre-Ryzen CPUs as the coverage for MOVEBE and the Bit Manipulation instructions are quite inconsistent.

TBH the case for Intel isn’t that much different they have (Atoms mainly) post-Haswell CPUs that don’t support all of the instructions in this patch that would fail the master CPUID check and would not receive the optimizations either.

If someone wants to split it into checking 30 specific CPUID flags and then figuring out which libraries can be linked because many of them would require some or all of these instructions by all means do that...

A relevant point here may be that with Zen2, just released and very popular, AMD supports AVX/AVX2 properly for the first time. Previous, AMD cpus could execute AVX instructions but it wouldn't actually be faster, so there was not much point in properly detecting that anyway. Now there is.

No,already the first Zen in 2017 supported perfectly AVX2. It just had half of the throughput of Haswell/Broadwell/Skylake. Nevertetheless, using 256-bit AVX instructions was still slightly faster in most cases than using 128-bit AVX or SSE, because less instructions had to be fetched and decoded.

When Zen was first released in 2017, using -march=haswell in gcc produced faster programs than using -march=znver1 or -march=bdverX.

Using AVX2 + FMA and all the other instructions introduced by Haswell & Broadwell was always the right thing to do when compiling for AMD Zen. Nothing has changed with Zen 2, except that the throughput of the AVX programs that are not limited by the memory throughput has doubled now.

Am I missing something? Intel submitted a patch in 2017 that enabled support for a feature that was supported in their processors. 2 years later, AMD still hasn't made processors that support one of those features (AVX512), and only recently released processors that met the requirements for the other haswell test... And somehow this is labeled "cripple AMD"?

It would be one thing if Intel did this while AMD had processors that worked on it.. but they didn't. And code cannot tell the future. That's why we have programmers. They're supposed to change the code when it needs to be changed.

> And code cannot tell the future.

In this case it doesn't need to, I believe. There are ways to find out at runtime which instruction sets are supported, in a vendor-agnostic way.

"Code cannot tell the future" is also the 2009 excuse Intel gave for icc not supporting processors that are GenuineIntel but not Family 6, incidentally. History is wonderful, isn't it? Back in the days we already knew what the still-current best practice to see what flags a CPU has is.

You can't expect Intel to know about obscure features like CPU feature flags, it's not like they invented it.... oh.

"only recently released processors that met the requirements for the other haswell"

This is false. Zen was introduced in Q1 2017, before that patch was written and it already implemented all the useful parts of the Skylake instruction set (and also the SHA extension not implemented by Skylake). The fact that the CPU vendor should not be used when testing for CPU features was already discussed a lot, many years ago, so someone of the library maintainers should have noticed this bug and removed the inappropriate test.

About AMD not supporting yet AVX-512, that is far less annoying than the fact that Intel does not support AVX-512 yet in any of their CPUs which are actually competitive in their target market (Ice Lake is worse than Comet Lake, Cascade Lake is worse than Epyc 2).

For me, skylake is useful because of AVX512{dq,bw}.

Skylake (i.e. Skylake, Kaby Lake and so on up to Comet Lake) does not support any AVX-512 instructions.

Only Knights Landing, Knights Mill, Skylake Server, Cascade Lake, Cannon Lake and Ice Lake support AVX-512.

What is called "Skylake Server" in the Intel documents, includes products sold under various names, i.e. Xeon Scalable, Xeon W, Xeon D-2xxx and Skylake-X (HEDT).

I assume that you were thinking about Skylake X, but those processors are a very small fraction of a percent in comparison with all the processors using the Skylake microarchitecture, which were sold since 2015 until now, so one should never use "Skylake" to speak about "Skylake Server" a.k.a. "Skylake X", because this is very misleading.

I see, thank you. I’ve only used skylake as skx, which just reflects what architectures I have access to.

Isn't it AMD's job, not GNU's job?

> something that should not happen in any free software package.

Some people takes "free software" pretty wrong. Free software doesn't mean being fair to all hardwares. It only is fair to accepting contributions from people who want their machines to work with it. They would be individual contributors but they are mostly people from the hardware vendors.

That's being said, Linux/Free software have being supporting Intel very well because Intel itself is one of the biggest contributor. It's time for AMD to hire more software engineers to support better drivers and software ecosystem.

No, it is GNU's job

Features have feature flags, you shouldn't be doing comparison like "this is an Intel model X then it runs this" but it should be "this has feature X then it supports X" period

It's the same crap as the ICC compiler throwing the slower code at AMD even though it would support the features

It's the job of the maintainer of glibc, but I think we can legitimately ask questions of Intel's contribution since it's pretty sneaky and in bad faith

Yes this should have been caught in a code review

The code is bad, it should detect features not vendor names . the proper fix should be CC-ed to the Intel developer so he can learn the good way of doing it.

This kind of bad code makes sites to ask me to run a modern browser just because my modern browser is not in the dev whitelist or this kind of bad code caused Microsoft not to have Windows9 because some developers where clever and instead of checking for features or check for win95 and win98 they wrote a shorter line of code and checked for "Win9".

In conclusion there are 2 possibilities:

1 the Intel dev did a mistake

2 it was intentional to limit the improvements to Intel only

you are arguing that 2 is fine, then you are fine if google, Facebooks, Microsoft also put checks in their commits and limit features only if the code runs in their OS,browser,site. This kind of obvious user hostile commits are bad and don't have a place in free software and IMO the Intel compiler should not intentionally cripple a competitor.

Also this attitude would mean that each company should now have a developer dedicated to check competitors contributions to make sure no intentional bad commits are sneak in because in your opinion is fair to intentionally do it.

> then you are fine if google, Facebooks, Microsoft also put checks in their commits and limit features only if the code runs in their OS,browser,site

In my experience some FB features (notes, maybe video) refuse to work on Firefox on *BSD. I tell it to lie about my UA and say that it's linux, everything works.

This is like a piece of JavaScript parsing User-Agent and looking for "Chrome 72.4" to decide whether it wants to work or not, instead of of detecting features.

Reply on news.ycombinator.com