4 ms·
Are any of these instruction sets available on M1? If not, what's the alternative there?
by kklisura 4y ago
Are any of these instruction sets available on M1? If not, what's the alternative there?
- RelentlessOpt 4y agoNo, AVX and AVX2 are amd64 things (Intel and AMD). The equivalent SIMD instruction set for arm64 (including the Apple M1) is called NEON. See https://developer.arm.com/documentation/ihi0073'/latest/' https://developer.arm.com/documentation/ihi0073'/latest/'
- DesiLurker 4y agoNo but an equivalent set of simd instructions called NEON are available. IMHO having programmed both the ARM ones seem to have less baggage and better designed. not sure about the performance of wider lane variants (512) on x86 though, they may be significantly faster.
- moonchild 4y agoCommon x86 impls have 2 or 3 vector pipes (recent intel is 2x avx512 or 3x avx2); apple arm has 4, so the difference in throughput, though definitely there, is less than you might expect. There is sve, which has variable-width vectors. Haven't played with it--that gets you your width, but there are obviously compromises there. The obvious longstanding omission from neon is movemask. One nice thing they have, though, is a permute with four source operands (!) for a 64-byte lookup table.
- janwas 4y agoWe have data from vqsort showing 3.2 GHz M1 to be half as fast as 3 GHz Skylake. I'd be interested in other direct comparisons of x86 vs NEON code :) SVE will be interesting especially when vectors get wider. For the Arm V1, there are some unfortunate bottlenecks. See Table 3.41 instruction throughput in https://documentation-service.arm.com/static/6088343f85368c4c2b1c26bb https://documentation-service.arm.com/static/6088343f85368c4... For OP's application, the equivalents of compressstore aren't great. COMPACT is decent (1x256-bit/cycle) but CNTP occupies the bottleneck M0 pipeline. Still, the V1 is probably fine for applications that do not often modify predicates.
- moonchild 4y agoI see. Sort is an interesting case because it has very tight dependencies (IOW, I expect there are many interesting workloads for which this result doesn't generalise). When you halve the vector width, you either double the length of the dependency chain or halve your effective work unit (which amounts to the same thing, along another axis--the performance impact of which is variable, but considering the m1 is very wide, it's probably not a great idea). I wonder if there's any room for a parallel sum scan, but my intuition is that, on a superscalar, at such small sizes, it's wasted work. While I haven't looked closely at vqsort yet, I was looking at vxsort not long ago. I suggested to its author the possibility of handling multiple partitions in parallel--handling only architectural vector per partition at a time--and he said that, while that seemed like a potentially promising approach, he was more immediately concerned with bandwidth. Considering the m1's great width, memory bandwidth, and cache size (on top of the small vector size), this seems like an especially promising approach there.
- janwas 4y agoI agree this is one specific use case. Decreasing the vector size does have some upside: it makes the O(lognlognn) sorting network cheaper. For M1, performance is not terrible, it seems mostly limited by the NEON instruction set (expensive to do masked stores and popcnt() comparison results). How do you mean multiple partitions in parallel? One challenge is that subarrays vary in size. It could be interesting to do multiway partition (larger base for the logn, fewer passes over memory), but that seems hard to reconcile with the vectorized in-place approach. ips4o effectively does a 64 or 256-way partition, but that's also nontrivial to vectorize.