3 ms·

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

by 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
    Right, it looks pretty reasonable to me too. Zen2 still doesn't have AVX-512 anyway, so the super parallel paths this aims to really help aren't applicable anyway. Zen1-2 should land on the "AVX 2 (Haswell)" path in the linked excerpt -- they have AVX/AVX2, F16C, OSXSAVE, and RDRAND -- which is the best ISA without AVX512 implemented in the compiler. That's entirely reasonable on Intel's part. (I don't know why they look for RDRAND in a compiler, but whatever.)
    - moonbug 7y ago
      Because it has an rdrand() function.
- gnufx 7y ago
  ARM seems a competitor to Intel in HPC, particularly in the Fujitsu post-K system (whose actual name I forget), but even the existing ThunderX2 systems. Interestingly, Intel people don't necessarily have the information to optimize for Intel CPUs even, and the hardware may not tell you. It's really complicated and messy. An example that's relevant to linear algebra is figuring out whether to use FMA, e.g. https://github.com/jeffhammond/vpu-count https://github.com/jeffhammond/vpu-count

by wahern 7y ago

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
  Right, it looks pretty reasonable to me too. Zen2 still doesn't have AVX-512 anyway, so the super parallel paths this aims to really help aren't applicable anyway. Zen1-2 should land on the "AVX 2 (Haswell)" path in the linked excerpt -- they have AVX/AVX2, F16C, OSXSAVE, and RDRAND -- which is the best ISA without AVX512 implemented in the compiler. That's entirely reasonable on Intel's part. (I don't know why they look for RDRAND in a compiler, but whatever.)
  - moonbug 7y ago
    Because it has an rdrand() function.
gnufx 7y ago
ARM seems a competitor to Intel in HPC, particularly in the Fujitsu post-K system (whose actual name I forget), but even the existing ThunderX2 systems. Interestingly, Intel people don't necessarily have the information to optimize for Intel CPUs even, and the hardware may not tell you. It's really complicated and messy. An example that's relevant to linear algebra is figuring out whether to use FMA, e.g. https://github.com/jeffhammond/vpu-count https://github.com/jeffhammond/vpu-count