3 ms·

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

> 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.
- admax88q 7y ago
  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.
  - cptskippy 7y ago
    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.
TomVDB 7y ago
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.
- Dylan16807 7y ago
  I don't understand your scenario. The minimal amount of effort includes a benchmark, so it wouldn't be enabled if it hurt performance.
  - TomVDB 7y ago
    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.
    - Dylan16807 7y ago
      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.

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.

admax88q 7y ago
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.
- cptskippy 7y ago
  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.

TomVDB 7y ago

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.

Dylan16807 7y ago
I don't understand your scenario. The minimal amount of effort includes a benchmark, so it wouldn't be enabled if it hurt performance.
- TomVDB 7y ago
  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.
  - Dylan16807 7y ago
    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.