janwas

6 ms·

1.
by janwas 24d ago
Great writeup, especially liked the line by line explanation :) We actually did manage to get dynamic dispatch working in Compiler explorer with Matt's help: https://gcc.godbolt.org/z/KM3ben7ET Maybe interesting
2.
by janwas 24d ago
Not seeing this at all. We routinely and easily target SSE4, AVX2, AVX-512 (in four variants) using the same application code in one binary. Frankly, this seems better to me than four separate RISC-V matmul extensions.
3.
by janwas 24d ago
The future is already partially here: see the recent "do we still need gpus" article.
4.
by janwas 25d ago
Not sure what this comment is based on. Arm introduced a scalable SIMD whose whole point is to be expandable. AVX-512 works very well, for example on Zen 4 and 5.
5.
by janwas 2mo ago
That is not at all my experience :) Please expand on what "vertically-oriented scope" means.
6.
by janwas 2mo ago
If you are running on large-scale data, have you validated at that scale (comparing results)? From a quick look at the code, it looks like there is a 42-bit hash (computed via single-mul hash function) which can have collisions and thus ret
7.
by janwas 2mo ago
hm, maybe not so trivially correct here. Do I understand correctly that incorrect results can happen as a result of a 42-bit hash collision? That could happen after less than one MB of input, given the simple one-mul hash. BTW throughput is
8.
by janwas 3mo ago
Author/Highway TL here. Happy to discuss.
9.
by janwas 4mo ago
Impressive result. Congrats!
10.
by janwas 4mo ago
Oops, the final T got cut off somehow, sorry about that. https://gcc.godbolt.org/z/KM3ben7ET
11.
by janwas 4mo ago
Any suggestions for improvement? We went through >5 iterations of the dispatching and I am fairly confident this is about as good as it gets in current C++. I suppose "macro hell" is a matter of taste. Objectively, we have six
12.
by janwas 4mo ago
Working on one together with fastcode.org :)
13.
by janwas 4mo ago
To be clear, "better abstractions" here seems to mean macros for assembly language. To each their own. What bothers me is advocating for this, or denigrating more generally useful alternatives, without mentioning the very narrow n
14.
by janwas 4mo ago
Correction (typo): Z13 lacks fp32.
15.
by janwas 4mo ago
Oh, interesting :) I meant Fastcode.org.
16.
by janwas 4mo ago
Is this a good faith reply? The particular abstraction we built, and is being discussed, is manifestly and obviously not a lowest common denominator. Looks like you are deploying a second straw man, that of zero cost. In other comments here
17.
by janwas 4mo ago
?? Where did you see mention of AI?
18.
by janwas 4mo ago
Thanks for sharing. The first link seems non public indeed. I can imagine there is some compile issue we could reasonably fix, with the help of someone who has Z13 access. Please encourage them to raise an issue. I will be back on May 26. A
19.
by janwas 4mo ago
Fair point. If it helps, our security team has called Highway critical infrastructure and helped to harden the repo. The flip side of standardization is that it would be much harder and slower to add ops as the need arises, which we do regu
20.
by janwas 4mo ago
:) I figure there is always something left to improve. For some kernels which really want to keep 30+ live registers, the compiler might not do as good a job as careful manual tuning, so intrinsics can have a bit of a cost. But I also figur
21.
by janwas 4mo ago
Yes, the EMU128 target is scalar only, with for loops. This is a fun way to see how well autovectorization works, with the same source code. That works on any CPU. Curious which projects have such concerns, any link?
22.
by janwas 4mo ago
In such discussions, whenever you mention abstractions are universally "pretty poor", to the extent anyone is listening, I think this hyperbole can do real damage. Maybe it prevents people from getting relevant performance gains
23.
by janwas 4mo ago
This works today :) Highway provides such an abstraction for arbitrary vector lengths and maps them to intrinsics. All on the library level, no need to wait years for compiler or language updates.
24.
by janwas 4mo ago
:) I agree a tutorial would be helpful. We are working on one with Fastcode.
25.
by janwas 4mo ago
Have you considered our Highway library? Runtime dispatch need not be a PITA :) It's basically portable intrinsics, and a much more complete set (>300) than the ~50 in std.
26.
by janwas 6mo ago
Highway TL here. I agree with the main points, with a few clarifications: > tag-dispatched free functions like hn::Mul(d, a, b) We only require tags for certain ops, mainly memory, casts and reduction; not arithmetic. Operator overloadin
27.
by janwas 6mo ago
Looks like the ratification plan for Zvzip is November. So maybe 3y until HW is actually usable? That's a neat trick with wmacc, congrats. But still, half the speed for quite a fundamental operation that has been heavily used in other
28.
by janwas 6mo ago
(Personal opinion) I get the impression that RISC-V-related discussions often lack of awareness of prior work/alternatives. A large amount of (x86) software actually uses our Highway library to run on whatever size vectors and instruc
29.
by janwas 8mo ago
:D Your code was nicely written and it was a pleasure to port to SIMD because it was already very data-parallel.
30.
by janwas 8mo ago
Gemma.cpp has nested thread pools, one per chiplet, and one across all chiplets. With such core counts it is quite important to minimize any kind of sharing, even RMW atomics.

More ›