7 ms·

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 supp

by krapht 7y ago

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.

acqq 7y ago
> 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.
- ori_b 7y ago
  So patch it. That's the point of free software: the freedom to modify it to your needs.
  - smcl 7y ago
    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.
    - jlg23 7y ago
      > 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.
      - alacombe 7y ago
        That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?
        jlg23 7y ago
        about 3 months ago, in a code audit.
    - randallsquared 7y ago
      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.
  - segfaultbuserr 7y ago
    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.
- luser1024 7y ago
  > 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".
  - Dylan16807 7y ago
    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.
Traster 7y ago
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.
        7y ago

by krapht 7y ago

acqq 7y ago

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

ori_b 7y ago
So patch it. That's the point of free software: the freedom to modify it to your needs.
- smcl 7y ago
  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.
  - jlg23 7y ago
    > 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.
    - alacombe 7y ago
      That's a myth. When was the last time you reviewed the technical aspect of heavily specific platform code in the glibc ?
      - jlg23 7y ago
        about 3 months ago, in a code audit.
  - randallsquared 7y ago
    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.
- segfaultbuserr 7y ago
  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.
luser1024 7y ago
> 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".
- Dylan16807 7y ago
  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.

Traster 7y ago

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