4 ms·

I don't understand why the multiple versions are a major concern? We shipped 3 codepaths for JPEG XL (SSE4/AVX2/AVX-512) with a binary size of a few hundred KiB

by janwas 4y ago

I don't understand why the multiple versions are a major concern? We shipped 3 codepaths for JPEG XL (SSE4/AVX2/AVX-512) with a binary size of a few hundred KiB. that's ~10 KLOC, and ~5-7 bytes per x86 vector instruction. it would be annoying to rewrite that per platform, but we didn't have to - github.com/google/highway (disclosure: I am the main author) provides portable intrinsics.

PaulHoule 4y ago
For most projects you're going to pick a small number of SIMD levels to support. (An extreme case: Apple it seems didn't want to write a WebP decoder for Safari that didn't depend on a recent instruction level for x86) Intel is probably going to be motivated to get maximum results on each CPU and today they are also thinking about FPGAs and how to get to get Intel GPU to compute faster than an abacus... On top of that I'd posit two complications with MKL. (1) is that the BLAS routines themselves are specialized in multiple versions. There are many things you might do differently depending on on the size of the problem and how it interacts with the cache, never mind the many different variations of functions that the user sees to deal with special case sparsities. N SIMD levels are multiplied by M variations for other reasons and NxM is getting big (2) is that the quality of software coming out of Intel is not that good. It seems Intel has the kind of culture that hires 10 junior engineers to accomplish what 0 experienced engineers could do. I am always seeing a press release saying they laid off 10,000 engineers and then a month later they are hiring another 10,000 engineers.
- janwas 4y ago
  I agree it makes sense to group the many x86 features into just 3-4 clusters, though Intel probably uses more. Makes sense that BLAS has many other variations. Still, hard to see why that necessitates gigabytes :)

by janwas 4y ago

PaulHoule 4y ago

For most projects you're going to pick a small number of SIMD levels to support. (An extreme case: Apple it seems didn't want to write a WebP decoder for Safari that didn't depend on a recent instruction level for x86) Intel is probably going to be motivated to get maximum results on each CPU and today they are also thinking about FPGAs and how to get to get Intel GPU to compute faster than an abacus... On top of that I'd posit two complications with MKL. (1) is that the BLAS routines themselves are specialized in multiple versions. There are many things you might do differently depending on on the size of the problem and how it interacts with the cache, never mind the many different variations of functions that the user sees to deal with special case sparsities. N SIMD levels are multiplied by M variations for other reasons and NxM is getting big (2) is that the quality of software coming out of Intel is not that good. It seems Intel has the kind of culture that hires 10 junior engineers to accomplish what 0 experienced engineers could do. I am always seeing a press release saying they laid off 10,000 engineers and then a month later they are hiring another 10,000 engineers.

janwas 4y ago
I agree it makes sense to group the many x86 features into just 3-4 clusters, though Intel probably uses more. Makes sense that BLAS has many other variations. Still, hard to see why that necessitates gigabytes :)