janwas

17 ms·

211.
by janwas 3y ago
Thanks for the link. We were previously using GFNI for bit reversal and 8-bit shifts, and I just extended that to our 8-bit BroadcastSignBit ( https://github.com/google/highway/pull/1784 ).
212.
by janwas 3y ago
Oh cool, nice that you edited Wikichip, thumbs up :)
213.
by janwas 3y ago
Minor correction: Cooper Lake added bf16. IEEE half-float fp16 only came in Sapphire Rapids (I am currently adding support for it in Highway).
214.
by janwas 3y ago
I do not understand how one would jump from the readme's "As of 2022-06-07 this sorts large arrays of built-in types about ten times as fast as `std::sort`" (and this is now being clarified to add LLVM's std::sort) to &#
215.
by janwas 3y ago
> Yes, only your "10x" and "5-10x" numbers are overstated. OK. I am curious: what is the desired outcome for you in this discussion? If we are arguing whether in some cases the speedup is 2x, I struggle to understand
216.
by janwas 3y ago
Oh, hi :) I like your unroller idea, it can simplify user code and is quite general. Agree about autovectorization. It is not even a true programming model, because we have only limited ability to influence results. Also agree std::simd is
217.
by janwas 3y ago
:) Thanks for the pointer. Glad to see simdeez now has a maintainer again. I believe its (mostly) 'abstracting SIMD width' feature is important and helps nudge people in a good direction.
218.
by janwas 3y ago
I understand it's much more convenient to develop on the machine that has it all. Further to the Godbolt suggestion, one band-aid is that Highway fairly efficiently emulates some of the fancier AVX-512 instructions such as CompressStor
219.
by janwas 3y ago
Yes, I've recently heard some mention of this survey being skewed/buggy, which is a pity because I do not know anything better. IIRC Linux systems were underrepresented.
220.
by janwas 3y ago
> vqsort authors found that at 1e8 elements a hybrid of ips4o (samplesort, think many-way partition) beats pure vqsort. Whoa, important caveat there: we did the hybrid with ips4o as an easy way of getting multicore support. We also menti
221.
by janwas 3y ago
What exactly do you see as overstated - only the "10x"? I realize characterizing sort performance with one number is very lossy, but consider "can be" to be a rather modest claim. > The 10x number is from comparing ag
222.
by janwas 3y ago
Wow, I find "vast vast vast" hard to believe. If we don't have loops where a lot of CPU time is spent, why even write in C++? I admittedly focus more on libraries, but quite a large number of them are already vectorized. I wo
223.
by janwas 3y ago
(Frequent AVX-512 user, opinions are my own.) It is time to stop quoting this rant, which is rather far removed from actual practice and reality. Specifically for sorting, Intel's sort and ours can be about 10x as fast as scalar. AVX-5
224.
by janwas 3y ago
Yes, can be about 1.6x speedup: https://github.com/Voultapher/sort-research-rs/blob/main/wri... (cpp_intel_avx512). Disclosure: I am the main author of vqsort, which is also a vectorized Quicksort but po
225.
by janwas 3y ago
Why not distribute a binary that uses AVX-512 if present, and falls back to AVX2 or SSE4 if not? It can be quite easy, see the example earlier in this thread.
226.
by janwas 3y ago
Runtime feature detection need not be rare nor hard, it's a few dozen lines of boilerplate. You can even write your code just once: see https://github.com/google/highway#examples .
227.
by janwas 3y ago
Sure, but one can first pin the thread to a core, or a "don't move me between core types" flag could be added to OSes.
228.
by janwas 3y ago
Cool that you started with SIMD :) FYI github.com/google/highway allows you to write your code once and target many instruction sets. It also fills in many of the gaps, including reductions. Disclosure: I am the main author.
229.
by janwas 3y ago
> According to the benchmarks in the article, many are also doing better at low-cardinality data. VQSort handles low cardinality quite well. Unfortunately only a few benchmarks in the article (not including that one) were re-run after ou
230.
by janwas 3y ago
Sharing some personal thoughts: Publishing a paper can be an imperfect, but useful 'expensive signal' that increases visibility. For vqsort, we initiated a collaboration with two universities who had published papers: KIT's i
231.
by janwas 3y ago
Cross-posting from https://news.ycombinator.com/item?id=36273544 : We looked into this [1] and conclude: - throttling is a non-issue on Xeon Gold/Platinum; - AVX-512 startup overhead can hurt on Skylake, but AVX-512 is
232.
by janwas 3y ago
Yes, vqsort does indeed resort to Heapsort after too many recursions. I'd be surprised if that happens on real data, though, because we apply a lot more effort to the pivot selection. Would be curious to see any input distribution that
233.
by janwas 3y ago
We looked into this [1] and conclude: - throttling is a non-issue on Xeon Gold/Platinum; - AVX-512 startup overhead can hurt on Skylake, but AVX-512 is still a net win for data sizes >= 100 KiB. - Startup overhead is a non-issue on
234.
by janwas 3y ago
Happy to discuss, preferably via issue on github.com/google/highway, would you like to open one?
235.
by janwas 3y ago
I'm the main author of Highway, so I have some opinions :D Number of operations/platforms supported are important criteria. A hopefully unbiased commentary: Simde allows you to take existing nonportable intrinsics and get them to
236.
by janwas 3y ago
I totally agree we don't want multiple optimized implementations, but that is no longer necessary. Highway (mentioned below) lets you write your code once but be compiled+specialized for the major SIMD targets. If you're writing
237.
by janwas 3y ago
I agree compiler transforms sometimes do not interact well, but some still do help intrinsics. Interestingly, even `#pragma clang unroll(4)` is ignored here. Often in such cases we have to manually unroll, e.g. introduce multiple accumulato
238.
by janwas 3y ago
Agreed. And I am not aware of a heapsort that can take advantage of SIMD, so our not very well-tuned heapsort is about 20 times slower in practice than our VQSort (vectorized quicksort).
239.
by janwas 3y ago
One possibility which seems not so well-known is that clocks with per-core state might not be perfectly synchronized. If your initial measurement is from core0, then we migrate to core1, the end measurement could even be 'before'
240.
by janwas 3y ago
I think crest may be referring to function multiversioning, but that only helps choose/call the implementation, not generate it. github.com/google/highway supports compiling your single source code once into several versions,

More ›