janwas

25 ms·

331.
by janwas 4y ago
Good news, you can use portable intrinsics (github.com/google/highway) and write your code only once. (Disclosure: I am the main author.)
332.
by janwas 4y ago
:) For anyone interested, here's a brief discussion of tail handling: https://github.com/google/highway#strip-mining-loops (Overlapping is indeed cool where it works - idempotent operations.)
333.
by janwas 4y ago
FWIW Windows has had something basically equivalent (IO completion ports) for quite some time. Indeed helpful, I remember that early SSDs already required high queue depths.
334.
by janwas 4y ago
Fair point :) I'm assuming the stack is doing what it can to avoid being the bottleneck. On a system level, I'd still call what you're describing CPU-bound, as in: unable to use all potential IO capacity.
335.
by janwas 4y ago
OK, if latency is a concern, is it possible to parallelize requests or increase batch sizes to maximize utilization and throughput?
336.
by janwas 4y ago
Business logic with tons of branches is indeed not amenable to SIMD, nor is that where the compute is. In a world with 400 Gb/s NICs, being IO bound takes some doing. How much SW manages that without SIMD, even on multiple cores?
337.
by janwas 4y ago
Agree that scatter is expensive. We did actually have hopes for 4-way partition. Even ignoring the difficulties with doing that in-place, SIMD partition still seems to require one compressstore per partition. A quick prototype turned out to
338.
by janwas 4y ago
I agree this is one specific use case. Decreasing the vector size does have some upside: it makes the O(logn logn n) sorting network cheaper. For M1, performance is not terrible, it seems mostly limited by the NEON instruction set (expensiv
339.
by janwas 4y ago
:) We (several engineers) put together a table [1] of instructions that several architectures natively support. There was enough overlap that I thought a wrapper would make sense. With a lot of the JPEG XL code written, when SVE and RVV wer
340.
by janwas 4y ago
We 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
341.
by janwas 4y ago
It depends on the CPU type (bronze/silver < gold/platinum). My workstation saw 1.4-1.6x end to end application speedups, including throttling (even on multiple cores) for JPEG XL decoding and vqsort. [ General observation, not
342.
by janwas 4y ago
Removal from Alder Lake was indeed regrettable but AVX-512 is still included in several recent client (non-server) CPUs: Icelake, Rocket Lake, Tiger Lake.
343.
by janwas 4y ago
Indeed a nice speedup! As to libraries: I'm the main author of github.com/google/highway which provides 'portable intrinsics' so you only have to write your code once for all platforms. It includes ready to use sort
344.
by janwas 4y ago
github.com/google/highway is arguably such a collection of tricks, the x86_256-inl.h header does emulate some missing AVX-512 instructions such as this one or compressstoreu. (In this case we currently use a constant.)
345.
by janwas 4y ago
Sounds good. This might be an interesting read in preparation for those: https://en.algorithmica.org/hpc/algorithms/argmin/
346.
by janwas 4y ago
It's often possible to avoid fringes via padding/overallocation. And if not, it may be possible to use unaligned loads/stores to handle the fringe in a single (final) iteration: https://github.com/google/
347.
by janwas 4y ago
I agree padding is a good solution when you can arrange it. In Highway we also use the blending/bit-select you mention: https://github.com/google/highway/blob/master/hwy/ops/generi... If H
348.
by janwas 4y ago
Author here. HighwayHash is indeed reasonably fast for a PRF/MAC/fingerprint, but our security claims are not strong enough for it to serve as a cryptographic hash. No collision nor preimage attacks are known to us, but it would n
349.
by janwas 4y ago
Thanks for the instruction table, hadn't seen that yet. That is indeed remarkably symmetrical! It does reinforce the "half of AVX-512" result - we sustain ipc=2 on Skylake (with 512-bit) and it looks like M1 would sustain 4 (
350.
by janwas 4y ago
I am that engineer; happy to clarify/go into more detail. First, just to ensure we're on the same page: the speeds we quote are sort goodput, i.e. amount of sorted data produced per time. Memory bus is only incidental to keeping t
351.
by janwas 4y ago
This is an interesting question. Has there been much uptake of such accelerators/coprocessors? One concern is that by the time the HW is ready, SW wants to do something different, perhaps fusing some other step with the sort. Another i
352.
by janwas 4y ago
If you're watching videos, quite a lot. Also, of the five image codecs mentioned here to succeed PNG/JPG, all have SIMD-enabled implementations: https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
353.
by janwas 4y ago
> adding SVE2 can be great for specific applications but it's really marginal when looking at whole system performance. What's not marginal are the improvements in power efficiency Depends on the applications, I suppose. But di
354.
by janwas 4y ago
Yes, this is discussed in section 4.2 of our paper: https://arxiv.org/pdf/2205.05982.pdf In short, it turns out not to help for single core with vectors, but a few initial passes of ips4o (with 64..256-way partitioning
355.
by janwas 4y ago
Response here because I'm not on Twitter: https://github.com/google/highway/issues/736 In short, what is being compared is O(1) djbsort sorting network, vs our full quicksort with pivot sampling, partiti
356.
by janwas 4y ago
It depends on the goals of the library maintainers. Users who really care about speed may already be using another library such as PDQsort or ips4o. Given that, the stdlib maintainers may reason that adding code and 'complexity' (
357.
by janwas 4y ago
I've read parts 1-5, there doesn't seem to be a part6. Thanks again for the link, it is regrettable that there is duplication of effort. His approach is quite similar to ours (including HeapSort, sorting network, unrolled in-place
358.
by janwas 4y ago
Good question. There are only a few functions implemented in .cc files, tagged with HWY_DLLEXPORT, notably memory allocation and detecting x86 CPU capabilities. If it were necessary, we could likely strip those out or do a header-only libra
359.
by janwas 4y ago
Depends on your goals? If you'd like to contribute code under Apache2, I'd be happy to collaborate. Feel free to reach out to the email in the Highway README. Some of the things on my short to medium-term todo list include: - Comp
360.
by janwas 4y ago
:) I'm curious why? But if so, you can have Compiler Explorer give you a starting point (assembly output) quickly.

More ›