dzaima

19 ms·

211.
by dzaima 1y ago
Heh, I've never noticed git commit including new file permissions on commit; definitely confusing/useless. Don't think "it prints less information" in general is a particularly good argument for user-friendliness th
212.
by dzaima 1y ago
As long as most people run with mitigations on, you're technically probably indeed safe. But you should still care that things get fixed with mitigations=on otherwise you wouldn't have the shield of "almost everyone has mitig
213.
by dzaima 1y ago
This is far from the first project to move from hg to git; many people probably just generally expect that to happen upon any source code management change for anything still using mercurial, which has already been effectively dead for most
214.
by dzaima 1y ago
AVX-10 used to have a AVX-10/256 version that's AVX-512 but without the 512-bit registers, but that's gone as of recently, so now AVX-10 is just a set of most AVX-512 extensions, and the stated goal is to, for future versions
215.
by dzaima 1y ago
That'd fail horrifically for guard pages around a main region where the whole used region is reasonably expected to be used. Considering that it'd be literally completely entirely unacceptable to ever hit such an emulated range in
216.
by dzaima 1y ago
Even that is somewhat bad, e.g. it means you miss "some_u64 = some_u32 * 8" losing bits due to promoting after the arith op, not before.
217.
by dzaima 1y ago
The main x86 to RISC-V instruction mapping is in this file: https://github.com/OFFTKP/felix86/blob/master/src/felix86/v2... That file is just testing I believe.
218.
by dzaima 1y ago
That's not a truth that'd come from first principles, never mind a trivial truth; it's extremely trivial to imagine a kernel that does parse PATH where it wouldn't be true. As such, it's a thing one has to explicitl
219.
by dzaima 1y ago
RISC-V does have a Zvkt extension that requires that the set of instructions useful for crypto have data-independent timing. (it includes requiring that shuffle timings are independent of table data, but allows timings to vary across differ
220.
by dzaima 1y ago
Chromium & Node (i.e. V8) do seem to just not normalize: arr = new Float64Array([0]); arr[0] = new Float64Array(new BigUint64Array([-123n]).buffer)[0]; [...new Uint8Array(arr.buffer)] // [133, 255, 255, 255, 255,
221.
by dzaima 1y ago
As long as you want all bit patterns to be Some float, there's not really one bit pattern you can chop out of somewhere (or, three, rather - both infinities, and NaN). Taking, say, the 3 smallest subnormal numbers, or the three largest
222.
by dzaima 1y ago
This doesn't work on Firefox, as it normalizes NaNs as they're extracted from ArrayBuffers. Presumably because SpiderMonkey uses NaN-boxing itself, and thus just doesn't have any way to represent actual non-canonical NaN floa
223.
by dzaima 1y ago
Because NaNs come from a standardized hardware-supported type, whereas the rest of those are largely language-specific (and you could consider null/nil as a "not-a-*" type for those in applicable languages; and there are lang
224.
by dzaima 1y ago
> Open source software is recompiled every week anyway. Despite being potentially compiled recently, anything from most Linux package managers, and whatever precompiled downloadable executables, even if from open-source code, still targe
225.
by dzaima 1y ago
ARM NEON does have sum, min, and max reductions (and/or reductions can just be min/max if all bits in elements are the same), along with pairwise ops. RVV has sum,min,max,and,or,xor reductions. x86 has psadbw which sums windows of
226.
by dzaima 1y ago
> The great joy of basic x86 encoding is that you don't actually need to put things in registers to operate on them. That's... 1 register saved, out of 16 (or 32 on AVX-512). Perhaps useful sometimes, but far from a particularl
227.
by dzaima 1y ago
SIMD only helps you where you're arithmetic-limited; you may be limited by memory bandwidth, or perhaps float division if applicable; and if your scalar comparison got autovectorized you'd have roughly no benefit. AVX-512 should b
228.
by dzaima 1y ago
Looks like that change is clang ≤19 to clang 20: https://godbolt.org/z/7zrocxGaq
229.
by dzaima 1y ago
Thanks for the info on how things look on the GPU side! A messy thing with memory performance on CPUs is that either you share the same cache hardware between scalar and vector, thereby significantly limiting how much latency you can trade
230.
by dzaima 1y ago
If you had two extra bits in the instruction encoding, I think it'd make much more sense to encode element width directly in instructions, leaving LMUL multiplier & agnosticness settings in vsetvl; only things that'd suffer th
231.
by dzaima 1y ago
That's two instrs - bumping the indices, and doing the comparison. You still want scalar pointer/index bumping for contiguous loads/stores (using gathers/scatters for those would be stupid and slow), and that gets you th
232.
by dzaima 1y ago
It takes like 4 instrs to compute the mask from an arbitrary length (AVX-512 doesn't have any instruction for this so you need to do `bzhi(-1, min(left,vl))` and move that to a mask register) so you still would likely want to avoid it
233.
by dzaima 1y ago
Oh, true, mistook it for an E-core while clicking through diagrams due to the port spam.. Still, that's a 2024 microarchirecture, it'll be like a decade before it's reasonable to ignore older ones.
234.
by dzaima 1y ago
Tail handling is not significant for loops with tons of iterations, but there are a ton of real-world situations where you might have a loop take only like 5 iterations or something (even at like 100 iterations, with a loop processing 8 ele
235.
by dzaima 1y ago
The limiting thing isn't necessarily speculating, but more just the number of branches per cycle, i.e. number of non-contiguous locations the processor has to query from L1 / uop cache (and which the branch predictor has to determ
236.
by dzaima 1y ago
Intel still shares ports between vector and scalar on P-cores; a scalar multiply in the loop will definitely fight with a vector port, and the bits of pointer bumps and branch and whatnot can fill up the 1 or 2 scalar-only ports. And maybe
237.
by dzaima 1y ago
ARM NEON is kinda misrepresented here - it supports both bitshifts by non-constants, and proper 32×32→32-bit multiplies; AVX2 also supports both of those.
238.
by dzaima 1y ago
I imagine a large part is just how one is used to doing stuff. Not being forced to be explicit about mutability and lifetimes allows a bunch of neat stuff that does not translate well to Rust, even if the desired thing in question might not
239.
by dzaima 1y ago
Right; the range reduction from [-pi;pi] would be like 5 instrs ("x -= copysign(pi/2 & (abs(x)>pi/2), x)" or so), ~2 cycles throughput-wise or so, I think; that's slightly more significant than I was imaginin
240.
by dzaima 1y ago
I'm of course not suggesting branching in cases where you expect a 30% misprediction rate. You'd do branchless reduction from [-2*pi;2*pi] or whatever you expect to be frequent, and branch on inputs with magnitude greater than 2*p

More ›