janwas

23 ms·

301.
by janwas 4y ago
Interesting, hadn't seen this before. So it's another side channel, one of many.
302.
by janwas 4y ago
Agreed. This is why it is even more important for the application to pad its arrays to the vector size. Then we might also skip the masking entirely.
303.
by janwas 4y ago
OK, it would indeed be nice if we only had to target AVX-512, but that's not the reality I'm in. On minimizing required emulation - any thoughts as to how? Padding data structures seems to be the biggest win, only mask/gather
304.
by janwas 4y ago
Thanks for the example. This seems like a reasonable thing to want, and as you say it's not ideal to SwapAdjacentBlocks and then shuffle again. It's not yet clear to me how to define an op for this that's useful in case vecto
305.
by janwas 4y ago
Yes, they theoretically could. The AMD manual contains this language: Exception and trap behavior for elements not selected for loading or storing from/to memory is implementation dependent. For instance, a given implementation may sig
306.
by janwas 4y ago
Thanks for the pointer. I read the video transcript and agree with their premise that indirect calls are slow. The are several ways to proceed from there. One could simply inline FastMemcpy into a larger block of code, and basically hoist t
307.
by janwas 4y ago
> while it may semantically be nicer to use masking everywhere, doing so is pretty bad for perf Agreed. It's best if applications pad data structures. > iirc AVX2's masks on AMD can still fault for masked out elements). Unfo
308.
by janwas 4y ago
hm, nifty - templates for x86 assembly language. Doesn't solve our requirement for portability across SVE/RISC-V, though :)
309.
by janwas 4y ago
Interesting, did not know that, thanks. It seems to me that a table of function pointers is all that's required. Highway is a little fancier in that the first entry is a trampoline that first detects CPU capabilities and then calls you
310.
by janwas 4y ago
hm, which AES? AES-128 is getting a bit tight already for multi-target attacks. As to quantum, it looks like practical serial or parallel application of Grover's algorithm might still be decades away. But that is with current knowledge
311.
by janwas 4y ago
Agreed. Do you have any example of an optimization of generic/cross-platform vector code, such that it would run better on SSE2 or SSSE3? One example might be reducing the number of live registers to avoid spilling, but you can already
312.
by janwas 4y ago
Thanks for your feedback! I'd be happy to advise on the port, feel free to open an issue if you'd like to discuss. I suppose there is a tradeoff between zero type safety + less typing, vs more BitCast verbosity but catching bugs s
313.
by janwas 4y ago
Thanks for the data point. Water cooled, impressive. But what is the problem here? Power is work per time. More power can be a good thing, especially if the work is useful. This is more likely in the SIMD case, which has much lower OoO cost
314.
by janwas 4y ago
That's a bold claim which requires extraordinary evidence. Sufficient counterexamples, most already mentioned in this discussion: databases, NN-512, TLS(AES), JPEG XL decoding (1.5x speedup), ...
315.
by janwas 4y ago
Hopefully they're updated for the new post-quantum algorithms. Which would you rather have: some fixed-function unit shared between all cores (load balancing? what if you're suddenly doing crypto stuff on many cores?), or the gene
316.
by janwas 4y ago
I feel that SIMD vs vector is not the most useful distinction to make. Yes, at the ISA and binutils level there is a difference in terms of number of instructions and ugly encodings. But the actual application source code can actually look
317.
by janwas 4y ago
:) C99 for FFI makes sense. It's pretty common to have a C-like function as the entry point for a SIMD kernel. That means it's feasible to build only the implementation as C++, right?
318.
by janwas 4y ago
How about porting to Highway, that gets you AVX-512, NEON and SVE(2) from a single rewrite :)
319.
by janwas 4y ago
> Except as an application author I can't rely on it being there. I'm surprised to keep hearing this concern. We can write code once in a vector-length agnostic way, compile it for multiple targets, and use whatever is there at
320.
by janwas 4y ago
Cool, I wasn't familiar with libvolk. It seems to be a collection of prewritten kernels, so it only helps if the function you want to write is among them. github.com/google/highway seems to be closer to what is requested here
321.
by janwas 4y ago
Author of Highway here :) PSHUFB is TableLookupBytes, or TableLookupBytesOr0 if you want its 0x80 -> 0 semantics. Can you help me understand why Highway might be more difficult to use? That would be very surprising if we are writing a la
322.
by janwas 4y ago
The turbo curves depend on the exact type of Xeon. Were they Bronze or Silver? Those are much worse in that regard. It is also unclear to me that AVX-512 is necessarily problematic in terms of power and thermal effects. Scalar code on many
323.
by janwas 4y ago
Disclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/a
324.
by janwas 4y ago
Reloading the page changed that for me.
325.
by janwas 4y ago
Nice data point. This is also relevant beyond qsort vs std::sort. Some implementations of Quicksort use a 3-way partition to save work for skewed inputs (if the pivot occurs often, no need to recurse for all those values). We have found tha
326.
by janwas 4y ago
Can you give a real example of AVX-512 actually causing a net performance penalty on any CPU? The only way I can see that happening is using AVX-512 in small, infrequently called functions such as strcmp, and the solution is: don't do
327.
by janwas 4y ago
> The gains AVX512 brings over AVX2 are, for most people w/ specialty libs excluded The last two things I worked on, image compression and quicksort, see 1.4-1.6x end to end speedups from AVX-512 vs AVX2. Is that sufficiently motiva
328.
by janwas 4y ago
Nice! Thanks for linking it :)
329.
by janwas 4y ago
Maxing out memBW requires multiple threads because Intel cores are relatively limited in line fill buffers. I've seen around 12 GB/s per SKX core with AVX-512.
330.
by janwas 4y ago
Indeed a great article, well worth reading in full for anyone who uses AVX-512. Two other things that jumped out at me: VPCONFLICT is 10x as fast, compressstoreu is >10x slower. Those might be enough to warrant a Zen4-specific codepath i

More ›