5 ms·

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 In

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.

jcelerier 7y ago
> 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.
- Bootvis 7y ago
  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.
  - jcelerier 7y ago
    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.
    - arghwhat 7y ago
      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.
      - rat9988 7y ago
        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.
        gtirloni 7y ago
        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.
        admax88q 7y ago
        > 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.
        cptskippy 7y ago
        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.
    - rocqua 7y ago
      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.
    - lidHanteyk 7y ago
      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.
- mcbits 7y ago
  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.
mannykannot 7y ago
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.
bin0 7y ago
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.
- justinjlynn 7y ago
  > 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.
  - big_chungus 7y ago
    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.
    - justinjlynn 7y ago
      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.
- robert-wallis 7y ago
  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.
wbl 7y ago
The optimization could be a slowdown on other chips. AMD uses narrower vectors then Intel for one.

jcelerier 7y ago

> 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.

Bootvis 7y ago
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.
- jcelerier 7y ago
  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.
  - arghwhat 7y ago
    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.
    - rat9988 7y ago
      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.
      - gtirloni 7y ago
        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.
      - admax88q 7y ago
        > 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.
        cptskippy 7y ago
        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.
  - rocqua 7y ago
    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.
  - lidHanteyk 7y ago
    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.
mcbits 7y ago
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.

mannykannot 7y ago

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.

bin0 7y ago

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.

justinjlynn 7y ago
> 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.
- big_chungus 7y ago
  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.
  - justinjlynn 7y ago
    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.
robert-wallis 7y ago
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.

wbl 7y ago

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