janwas

27 ms·

1. 241.▲
   by janwas 3y ago

   The union work turns out to be a lot because compiler extensions and simd<> barely support anything beyond operators. Examples of what's missing: interleaved load/store, compress/expand, software AES/CLMUL, popcoun
2. 242.▲
   by janwas 3y ago

   Fair point :) I wonder why the kernel is so aggressive about migrating threads, it also loses the cache contents. FWIW our command line tools at one point pinned themselves to the current core, which did help performance.
3. 243.▲
   by janwas 3y ago

   hm, that seems optimistic for this use-case. I heard from a compiler engineer that autovectorizing a sort (which is full of permutes/shuffles) is much harder and is likely to remain infeasible for quite some time.
4. 244.▲
   by janwas 3y ago

   Or a portable one that already works on Arm, RISC-V, AVX2 etc :) See the vqsort link above.
5. 245.▲
   by janwas 3y ago

   Thanks :) We do not have JVM bindings. I am not familiar with Java internals but would be happy to consider maintaining them if someone wants to add them (plus a test).
6. 246.▲
   by janwas 3y ago

   As to portability to other SIMD instruction sets: vqsort[0] is portable to >10 different instruction sets, and actually faster than this when running on AVX-512. Disclosure: I am the main author; happy to discuss. 0: https://g
7. 247.▲
   by janwas 3y ago

   It doesn't have to be as verbose and cryptic as intrinsics; wrapper functions can help a lot :) Is this more readable? https://github.com/google/highway/blob/master/hwy/contrib/so...
8. 248.▲
   by janwas 3y ago

   That's surprising, I would expect that codecs are doing enough work that the faster processing from AVX-512 more than pays for the downclocking. In JPEG XL we saw 1.4x end to end speedup (including this downclocking) and that was for i
9. 249.▲
   by janwas 3y ago

   Thanks, glad to hear :) Feedback is always welcome, do let us know via Github issue if there is anything you think can be improved.
10. 250.▲
    by janwas 3y ago

    Here is an example on how to do this using github.com/google/highway: https://gcc.godbolt.org/z/zP7MYe9Yf You write the code only once and do not have to worry about any #pragma/conditional compilation.
11. 251.▲
    by janwas 3y ago

    Cool, thanks for sharing, wasn't aware of those. It is natural that C has about zero emulated operators - today's CPUs are compatible with ones likely built with that use-case in mind. That is a low bar for comparison, especially
12. 252.▲
    by janwas 3y ago

    Yes, I appreciated your previous list of 'things it would be better to work around if possible'. But "a large amount of operations will just suck" did sound overly pessimistic :) We are talking about a small percentage o
13. 253.▲
    by janwas 3y ago

    This seems overly pessimistic :) We have actually implemented all of those things except first-fault loads in a cross-platform way at reasonable cost in https://github.com/google/highway . If any of those is the one mis
14. 254.▲
    by janwas 3y ago

    :) Yes indeed! Always happy to discuss suggestions for new intrinsics via Github issues.
15. 255.▲
    by janwas 3y ago

    Fair point, but we find it useful to have a few clusters: SSE4, AVX2 (Haswell), Skylake, newer AVX-512 Icelake/Zen4. That's still manageable, we're just compiling the SIMD parts 4 times and binary size impact is very modest (
16. 256.▲
    by janwas 3y ago

    Mostly agree, but there is actually a mismatch between madd_epi16 and Arm. Implementing Arm semantics or x86 on the other requires ~5 instructions, but if we generalize the definition to allow reordering (e.g. Highway's ReorderWidenMul
17. 257.▲
    by janwas 4y ago

    (For completeness, the bug was only x86-simd-sort lacking support for reverse sort, which our benchmark tests for.)
18. 258.▲
    by janwas 4y ago

    I've posted bench_sort results in another thread. vqsort is about 1.8 times as fast for uniform random 32/64-bit.
19. 259.▲
    by janwas 4y ago

    Thanks for sharing. I've posted bench_sort results in another thread. vqsort is about 1.8 times as fast for uniform random, a bit more of an advantage than your results here. Note that there appears to be some bug because our benchmark
20. 260.▲
    by janwas 4y ago

    Benchmark results using vqsort's bench_sort on Skylake workstation (patch: https://github.com/google/highway/pull/1140 ) vqsort is about 1.9x and 1.8x as fast on 1M keys and 100M uniform random keys, resp
21. 261.▲
    by janwas 4y ago

    OK, I think we meet those criteria. JPEG XL can use Highway via add_subdirectory, assuming that is what you mean by sub-project.
22. 262.▲
    by janwas 4y ago

    Got it. Highway is mostly header-only and we can move towards fully if anyone is interested. We also have a CMake build, not sure about well-engineered but patches welcome from anyone with more CMake expertise :)
23. 263.▲
    by janwas 4y ago

    sagarm has posted one result in another thread. I'll also look into adding their code to our benchmark :) It's great to see more vector code, but caveat for anyone using this: the pivot sampling is quite basic, just median of 16 e
24. 264.▲
    by janwas 4y ago

    Thanks for sharing the benchmark :D Is there anything we could do to make Highway/vqsort (feel like) a lighter dependency?
25. 265.▲
    by janwas 4y ago

    Thanks! Yes indeed. Halide has good support for stencils and convolutions, especially taking care of the border handling, which is a pain with explicit SIMD if you are unable to 'define that away' by padding etc. Boilerplate is a
26. 266.▲
    by janwas 4y ago

    :) There are some wasm vs native benchmarks in the context of JPEG XL (for example https://github.com/niutech/jxl.js#benchmark ) Could also be interesting for you to run the vqsort benchmark: https://github.c
27. 267.▲
    by janwas 4y ago

    Thanks! > Do you think it would be possible to port this to Rust? Yes, I think so. The main tricks are redefining macros based on the current compilation target, and compiling the same code multiple times. I believe Rust can do both, but
28. 268.▲
    by janwas 4y ago

    SLEEF comes with an abstraction layer (mostly for math). Instead of C++ function overloading, it uses type suffixes: https://github.com/shibatch/sleef/blob/master/src/arch/helpe...
29. 269.▲
    by janwas 4y ago

    Agree that OoO is the big cost. But we can also mitigate that without VLIW: SIMD/vector reduces the instruction count by ~5x, and energy by a similar factor. And a portable API such as Highway also helps us move the same code from x86
30. 270.▲
    by janwas 4y ago

    Author here, happy to discuss.