dzaima

36 ms·

481.
by dzaima 2y ago
I don't disagree that the real-world difference is massive; that much is pretty clear. I'm just pointing out that, as far as I can tell, it's all just a question of a constant factor, it's just massive. I've written
482.
by dzaima 2y ago
Huh, in what situation would vl=0 clobbering registers be undesirable while on vl≥1 it's fine? If hardware will be predicting vl, I'd imagine that would break down anyway. Potentially catastrophically so if hardware always chooses
483.
by dzaima 2y ago
If anything, I'd say x86's fixed operands make register allocation easier! Don't have to register-allocate that which you can't. (ok, it might end up worse if you need some additional 'mov's. And in my experien
484.
by dzaima 2y ago
What's the "nice to have feature" of vl=0 not modifying registers? I can't see any benefit from it. If anything, it's worse, due to the problems on reduce and vmv.s.x.
485.
by dzaima 2y ago
> Agree agnostic would help, but the machine also has to handle SW asking for mask/tail unchanged, right? The agnosticness flags can be forwarded at decode-time (at the cost of the non-immediate-vtype vsetvl being very slow), so for
486.
by dzaima 2y ago
How does avl affect register renaming? (there's the edge-case of vl=0 that is horrifically stupid (which is by itself a mistake for which I have seen no justification but whatever) but that's probably not what you're thinking
487.
by dzaima 2y ago
Expanding on 3: I think it ends up at O(n^2 * log n) transistors, O(log n) critical path (not sure on routing or what fan-out issues might there be). Basically: determine end of instruction at each byte (trivial but expensive). Determine en
488.
by dzaima 2y ago
More RVV questionable optimization cases: - broadcasting a loaded value: a stride-0 load can be used for this, and could be faster than going through a GPR load & vmv.v.x, but could also be much slower. - reversing: could use vrgather (
489.
by dzaima 2y ago
> My favorite absurdity of x86 (though hardly the only one) is padding. You want to align function calls at cacheline boundaries, but that means padding the previous cache line with NOPs. Those NOPs translate into uops though. I'd c
490.
by dzaima 2y ago
That's still silicon spent on a problem that can be architecturally avoided.
491.
by dzaima 2y ago
> Packed SIMD doesn't even have LMUL>1, so the comparison here is that you are usually the same as Packed SIMD, but can sometimes be better which isn't a terrible place to be. Packed SIMD not having LMUL means that hardware
492.
by dzaima 2y ago
I know the E-cores (gracemont, crestmont, skymont) have the multi-decoder setup; the first couple search results don't show Golden Cove being the same. Do you have some reference for that? 6. Ah yeah the funky SSE4a thing. RISC-V has i
493.
by dzaima 2y ago
Some notes: 3: I don't think more decoders should be exponentially more complex, or even polynomial; I think O(n log n) should suffice. It just has a hilarious constant factor due to the lookup tables and logic needed, and that log fac
494.
by dzaima 2y ago
RISC doesn't imply wasted instruction space; RISC-V has a particularly interesting thing for this - with the compressed ('c') extension you get 16-bit instructions (which you can determine by just checking two bits), but with
495.
by dzaima 2y ago
ARM doesn't need the variable-length instruction decoding though, which on x86 essentially means that the decoder has to attempt to decode at every single byte offset for the start of the pipeline, wasting computation. Indeed pretty mu
496.
by dzaima 2y ago
The various mentioned power consumption amounts are 4-10% per-core, or 0.5-6% of package (with the caveat of running with micro-op cache off) for Zen 2, and 3-10% for Haswell. That's not massive, but is still far from what I'd con
497.
by dzaima 2y ago
https://stackoverflow.com/questions/1367409 has varying amounts of CSS for that, ranging from bad (i.e. more than one line, i.e. the bar to beat for people to automatically use it over <a>) to horrific. Looks lik
498.
by dzaima 2y ago
And it gives some baseline accessibility functionality. Sucks that there isn't any gerneral "I am clickable" element that neither has bad default click behavior, nor has its own likely-unfitting styling.
499.
by dzaima 2y ago
Even if a project can choose some specific feature(s) to switch to C++ for, it'd severely reduce the barrier for adding reliance on more features; why did feature X get a pass, but not this other one? And C++ has a lot of such potentia
500.
by dzaima 2y ago
For unified scalar and vector instructions, MRISC32 might be interesting: https://mrisc32.bitsnbites.eu/ . Though it still has separate vector & scalar register files, and I don't think it's intended for the ty
501.
by dzaima 2y ago
Intel has shared ports across scalar and SIMD for a long time (only recently they've split them apart). I don't know whether they share silicon though, quite likely that they don't. The complexity of using parts of vector ALU
502.
by dzaima 2y ago
Another concern besides register file size is shuffle instructions, which can transfer any byte of a 512-bit register to any other (or any byte across two such registers for another instruction variant (vpermt2b), i.e. selecting from 128 by
503.
by dzaima 2y ago
That's just a font with a ligature for "0x".
504.
by dzaima 2y ago
All registers are basically always treated the exact same in OoO-land (though on x86-64 for some instruction forms it can add an extra byte of instruction encoding if there's some operand in r8..r15). But there's still a massive a
505.
by dzaima 2y ago
There's already an x86-64 extension for this: RAO-INT (remote atomics).
506.
by dzaima 2y ago
If you have, say, 'add r1, r2, r3; add r2, r2, 1' and want to do the latter instruction in-register-file, you can't reorder them (e.g. if r2 is known before r3) as after having ran the second instruction the first ones r2 ope
507.
by dzaima 2y ago
> No, it means that the bug is documented to be in the platform, not the program. Yes, it means that the platform is buggy, but that doesn't help anyone wanting to write portable-in-practice code. The standard specifying specific be
508.
by dzaima 2y ago
> Backwards compatibility? I thought that was a target for WG14. C23 removed K&R function declarations. Indeed backwards-compatibility is important for them, but it's not the be-all end-all. Having a standard state exact possibl
509.
by dzaima 2y ago
If SQLite wants exactly C89, it can just require -std=c89, and then people compiling it with a different standard target are to blame. This is just standard backwards incompatibility, nothing about UB (in other languages requiring specific
510.
by dzaima 2y ago
So your issue is not at all any specific thing or action anyone took, but just in general having UB in places not strictly necessary. And "Especially anything [different from The Golden Days]", besides being extremely cliche, is a

More ›