5 ms·

It's open source, so it should be fine? But Intel's history when it comes to compilers and applied optimisations leaves this making me immediately uncomfortabl

by yarg 7y ago

It's open source, so it should be fine? But Intel's history when it comes to compilers and applied optimisations leaves this making me immediately uncomfortable. The sort of PR work that these guys would need to do in order for me to consider them even remotely trustworthy is beyond even their budget.

insulanus 7y ago
I assume you're referring to Intel's robust history of "Intellectual Property" lawsuits? Agreed. ISPC is under a BSD license, but I wonder if there's a lawsuit to be made from the use of the techniques.
- frostburg 7y ago
  He's probably referring to Intel compilers outputting code designed to slow down CPUs from other makers.
  - amiga-workbench 7y ago
    And this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour.
    - wolfgke 7y ago
      > And this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour. A benchmark whose speed also depends on a compiler is not a benchmark of the CPU, but of a combination compiler/CPU. If this is not written down (and, of course, also written down which compiler was used), it is a deception of the reader.
      - rbanffy 7y ago
        During the UNIX wars, it was suspected many companies tuned their compilers to generate unrealistically fast code for common benchmarks.
      - ncmncm 7y ago
        All benchmarks depend on both the CPU and the compiler -- except those coded in assembly language. Everybody knows it, so it is not (by itself) a deception.
wahern 7y ago
You don't have to guess. The process of upstreaming and the [then] current state of ARM support is described here: https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.html https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.ht... Not sure what conclusions to draw from that, but it looks like ARM support was finally made first class this past August: https://github.com/ispc/ispc/blob/cf90189/docs/ReleaseNotes.txt https://github.com/ispc/ispc/blob/cf90189/docs/ReleaseNotes.... I think it might be difficult to purposefully cripple AMD in an open source project.
- loeg 7y ago
  > I think it might be difficult to purposefully cripple AMD in an open source project. It's not as explicit as it has been in the past, but the CPUID checks for very specific feature sets aligned with particular Intel models may not match AMD models, producing worse code on AMD models that support featuresets above baseline AVX2: https://github.com/ispc/ispc/blob/master/check_isa.cpp#L106-L140 https://github.com/ispc/ispc/blob/master/check_isa.cpp#L106-... That said, I don't assume malice here and I haven't investigated thoroughly. Most likely they just want to support their own silicon well and that's what they know. It's possible they would accept similar support for AMD µarchs in the OSS project (or maybe not). I wouldn't draw too much inference from the ARM example, as I don't see ARM as an Intel competitor. AMD, on the other hand, is currently very competitive with Intel.
  - mcbain 7y ago
    I’ve spent time writing CPU detection code for previous projects, and there is nothing that jumps out at me as biased in the linked ISA check. In fact that is really the bare minimum required to split the AVX variants, and will detect AMD support just the same as Intel. You can compare it to other detection functions - one relatively easy to read, non-vendor biased example that does dig into all the extensions is this Go implementation (not mine): https://github.com/klauspost/cpuid/blob/master/cpuid.go https://github.com/klauspost/cpuid/blob/master/cpuid.go
    - loeg 7y ago
loeg 7y ago
Just search the github repo for "cpuid." It's used in two files, and while it does select for featuresets of Intel-specific models, it does so using common feature bits that AMD can implement, and has a fallback path for baseline AVX2-only mode. It isn't clear that they intentionally cripple AMD in any way. There is no explicit check for GenuineIntel, for example.
BubRoss 7y ago
Why would you need 'PR' to trust something. Just compile your program and try it.
- yarg 7y ago
  I'm not saying that it won't work - but I'd be very surprised if it was well optimised for any vendor other than Intel. This in and of itself is not proof that they are operating in bad faith; if they provide clean interfaces and reasonable default implementations that's all that can be justifiably expected of them. The question of good faith actually only comes into play when another vendor provides their own optimised implementations and creates a pull request. How will the project maintainers respond? Even getting to that point requires a trust based buy in to the project from the other vendor. Given Intel's history of toxic behaviour in competition I think they need to do far more than they have done (and are likely to ever do) to earn that minimal baseline of trust.
  - BubRoss 7y ago
    This is an open source project that came from a single person inside Intel. Intel is a huge company and this project is barely a blip on priorities. You don't have to gues, go try it or do some research. It has been maintained for many years now, you can see all of the history on GitHub.

by yarg 7y ago

insulanus 7y ago

I assume you're referring to Intel's robust history of "Intellectual Property" lawsuits? Agreed. ISPC is under a BSD license, but I wonder if there's a lawsuit to be made from the use of the techniques.

frostburg 7y ago
He's probably referring to Intel compilers outputting code designed to slow down CPUs from other makers.
- amiga-workbench 7y ago
  And this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour.
  - wolfgke 7y ago
    > And this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour. A benchmark whose speed also depends on a compiler is not a benchmark of the CPU, but of a combination compiler/CPU. If this is not written down (and, of course, also written down which compiler was used), it is a deception of the reader.
    - rbanffy 7y ago
      During the UNIX wars, it was suspected many companies tuned their compilers to generate unrealistically fast code for common benchmarks.
    - ncmncm 7y ago
      All benchmarks depend on both the CPU and the compiler -- except those coded in assembly language. Everybody knows it, so it is not (by itself) a deception.

wahern 7y ago

You don't have to guess. The process of upstreaming and the [then] current state of ARM support is described here: https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.html https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.ht... Not sure what conclusions to draw from that, but it looks like ARM support was finally made first class this past August: https://github.com/ispc/ispc/blob/cf90189/docs/ReleaseNotes.txt https://github.com/ispc/ispc/blob/cf90189/docs/ReleaseNotes.... I think it might be difficult to purposefully cripple AMD in an open source project.

loeg 7y ago
> I think it might be difficult to purposefully cripple AMD in an open source project. It's not as explicit as it has been in the past, but the CPUID checks for very specific feature sets aligned with particular Intel models may not match AMD models, producing worse code on AMD models that support featuresets above baseline AVX2: https://github.com/ispc/ispc/blob/master/check_isa.cpp#L106-L140 https://github.com/ispc/ispc/blob/master/check_isa.cpp#L106-... That said, I don't assume malice here and I haven't investigated thoroughly. Most likely they just want to support their own silicon well and that's what they know. It's possible they would accept similar support for AMD µarchs in the OSS project (or maybe not). I wouldn't draw too much inference from the ARM example, as I don't see ARM as an Intel competitor. AMD, on the other hand, is currently very competitive with Intel.
- mcbain 7y ago
  I’ve spent time writing CPU detection code for previous projects, and there is nothing that jumps out at me as biased in the linked ISA check. In fact that is really the bare minimum required to split the AVX variants, and will detect AMD support just the same as Intel. You can compare it to other detection functions - one relatively easy to read, non-vendor biased example that does dig into all the extensions is this Go implementation (not mine): https://github.com/klauspost/cpuid/blob/master/cpuid.go https://github.com/klauspost/cpuid/blob/master/cpuid.go
  - loeg 7y ago

loeg 7y ago

Just search the github repo for "cpuid." It's used in two files, and while it does select for featuresets of Intel-specific models, it does so using common feature bits that AMD can implement, and has a fallback path for baseline AVX2-only mode. It isn't clear that they intentionally cripple AMD in any way. There is no explicit check for GenuineIntel, for example.

BubRoss 7y ago

Why would you need 'PR' to trust something. Just compile your program and try it.

yarg 7y ago
I'm not saying that it won't work - but I'd be very surprised if it was well optimised for any vendor other than Intel. This in and of itself is not proof that they are operating in bad faith; if they provide clean interfaces and reasonable default implementations that's all that can be justifiably expected of them. The question of good faith actually only comes into play when another vendor provides their own optimised implementations and creates a pull request. How will the project maintainers respond? Even getting to that point requires a trust based buy in to the project from the other vendor. Given Intel's history of toxic behaviour in competition I think they need to do far more than they have done (and are likely to ever do) to earn that minimal baseline of trust.
- BubRoss 7y ago
  This is an open source project that came from a single person inside Intel. Intel is a huge company and this project is barely a blip on priorities. You don't have to gues, go try it or do some research. It has been maintained for many years now, you can see all of the history on GitHub.