dzaima

53 ms·

691.
by dzaima 3y ago
This is at least somewhat wrong at best - SVE2 doesn't have a dynamic vector length like RVV (only non-fixed hardware register width, and masking), and Cray-1, said to be the first vector processor, has a fixed hardware register size (
692.
by dzaima 3y ago
You're comparing a crappy password filter with an optimally implemented passkey thing, though. If the world's up for improving over status quo by rewriting all login prompts, the comparable options would be making password manager
693.
by dzaima 3y ago
The linked problem goes far past the result object being unstable though - namely, with it you can affect any string in any class file that the JVM loads in the future. That is, you can get yourself into a situation where the following func
694.
by dzaima 3y ago
A flags register is "threaded through the entirety of the program" just as much as all other registers. Though lui+add does have the benefit that the add should write over the lui result, whereas cmp+branch needs to both update th
695.
by dzaima 3y ago
Well, that existing RISC-V hardware is also significantly slower than modern x86/ARM, so judging the importance of fusion from them is pretty meaningless. Surprise, there's a bunch of x86 & ARM hardware without fusion (or very
696.
by dzaima 3y ago
Somewhat related: https://dougallj.wordpress.com/2020/05/10/bitwise-conversion... That implements conversion from an IEEE-754 double to a pair of two such doubles whose values are integers of the low and high
697.
by dzaima 3y ago
> There will me gigabytes of dependencies or object files that aren't needed taking up space. Among the couple dozen things I've got built from source, most have their object files sum up to less than the 117MB of a libLLVM-15.
698.
by dzaima 3y ago
But at which point would they stop being persisted? Surely not right after the build completing, so.. requiring manually running some "ok now clean redownloadable dependencies" command (noone's gonna bother, and at that point
699.
by dzaima 3y ago
> You don't need to install a toolchain to use it. The build tool should handle everything for you and should handle clearing caches of unsued toolchains that are no longer needed. I don't want a dozen clangs and gccs wasting d
700.
by dzaima 3y ago
The two options of reproducible builds and prebuilt artifacts is still a significantly limiting situation. There are plenty of situations where the desired prebuilt artifacts aren't available, and you'd prefer to not have 5 clang-
701.
by dzaima 3y ago
That's an interesting use-case, though I wouldn't be surprised if some impls really wouldn't like LMUL dynamically switching at runtime a lot (i.e. something like LMUL being forwarded at decode-time, so it couldn't decod
702.
by dzaima 3y ago
I believe what camel-cdr is saying is being able to run the same code without duplication (say, a loop) which has no vsetvl-s inside, by conditionally choosing either an initial "vsetvli x0,x0,e32,m1" or "vsetvl x0,x0,e16,m1&
703.
by dzaima 3y ago
You sould branch at the level where inlining doesn't make sense, which would usually be some function wrapping the big loop, which should be rather free. Which is the same situation as on x86-64 if you want to target pre-AVX2/post
704.
by dzaima 3y ago
Not really - you don't need to dispatch anything, the idea is that the same code (and thus the same assembly/machine code) can operate on different sizes by itself. e.g. with RVV "vsetvli x0,x0,e32,m1,ta,ma; vadd.vv v0, v1, v
705.
by dzaima 3y ago
The problem isn't detecting the width (that's trivially possible at runtime with a single instruction, though both SVE and RVV have a way to write loops such that you don't even need to). The problem is that a "Simd<i
706.
by dzaima 3y ago
That's 5 copies for SVE (had an error in first message - SVE allows up to 2048-bit vectors, not 1024), and 10 copies for RVV if you wanted to target all widths (though you'd probably be fine for a decade or a couple by targeting j
707.
by dzaima 3y ago
A problem is that most such things (the rust thing, C++'s experimental/simd, Zig's SIMD types) have the vector size as a compile-time property, while ARM's SVE and RISC-V's RVV are designed such that it's possi
708.
by dzaima 3y ago
0.5 CPI is for the 128-bit or 256-bit versions; 512-bit ones are 1 CPI. Same on Zen 4 according to uops.info - https://uops.info/table.html?search=vgf2p8affineqb%20zmm&cb_...
709.
by dzaima 3y ago
Yeah the edited version is correct; it matches up each group of eight "x" values with one "A" matrix (such that, in the bitwise representation of the arguments, there's no data transfer happening across 64-bit block
710.
by dzaima 3y ago
Not quite - in "A * x + b", "A" is an 8×8 matrix, while "x" and "b" are 8-bit vectors. (it's vectorized over "A" and "x", but not "b", which is the immediate value)
711.
by dzaima 3y ago
It is very much true that there's a very large amount of things that could be improved on the status quo with rather minimal amounts of effort, that could resolve a vast majority of the brokenness of responsiveness of UIs. But decreasi
712.
by dzaima 3y ago
The reality is that optimizing for the common scenario just gives such significant benefits that the worst-case scenario becomes practically infeasible to even consider. And it's not just OSes that don't particularly care about re
713.
by dzaima 3y ago
For most specific purposes, a specialized bump allocator can be significantly more optimized. Hard-coding the alignment simplifies many questions (especially if you can guarantee the allocation size being a multiple of the alignment, at whi
714.
by dzaima 3y ago
That's C++, which is not C. Granted, the C++ behavior is weird and annoying. (the C behavior, while better for truly-infinite loops, is still "broken" for potentially-not-but-still-possibly-infinite loops, though such should
715.
by dzaima 3y ago
N1570, 6.8.5, point 6 under "Semantics": An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs
716.
by dzaima 3y ago
The present behavior on normal 32-bit and 64-bit platforms is that, on both, 'int' is 4 bytes, and 'long long' is 8 bytes; and on 64-bit, whether 'long' is 4 or 8 bytes depends on the ABI/target OS. I&#x27
717.
by dzaima 3y ago
sizeof isn't an obscure part of the language, yes, but the specific behavior here might still be unexpected for a decent number of people, who might, say, think they can always use "sizeof(int)" and "4" interchangea
718.
by dzaima 3y ago
But, thus, upon seeing the program, without additional information you cannot know whether it'll give 8 or 3 (or who knows what else), and thus "I don't know." is very much an appropriate answer. Of course, it might be m
719.
by dzaima 3y ago
"are simply wrong" and "under any reasonable compiler" don't mix - yes, for arm(32/64)/x86(-32 or -64) there are common values, but that doesn't make everything else not exist. OP doesn't say tha
720.
by dzaima 3y ago
True, Intel could've been influenced if there was an expectation on the behavior of shifts. But I doubt they'd have made two versions, and we'd just be stuck with the less useful mod 32/64 one.

More ›