dzaima

39 ms·

571.
by dzaima 2y ago
Take for example the compiler optimizing: void foo(bool cond) { int a = 0; if (cond) a = 10; if (cond) printf("%d\n", 10 / a); } into: void foo(bool cond) { int a = 0; if (cond
572.
by dzaima 2y ago
That's an option for a potential 2x boost, which I suppose could be good enough in certain contexts, but that's it. In particular, if you have a parser system able to utilize SIMD for all parsing, that'll get arbitrary parall
573.
by dzaima 2y ago
There's not really that much specific to change I think; the general thing is just reducing the number of rules, as in a parallel thing you'll be applying every rule to every part versus just the rules given preceding context (the
574.
by dzaima 2y ago
There's a surprising amount of things that are possible to parse in a parallel fashion if one tries hard enough, though keeping significant or any gains is more tricky. The operation in the article though is only a rather tiny part of
575.
by dzaima 2y ago
Closest you can realistically get in current compilers is adding some no-op asm statement "modifying" some subexpression as an "optimization barrier". e.g. __asm__("" : "=r"(x) : "0"(x
576.
by dzaima 2y ago
This doesn't help help with ARM, which doesn't have a separate feature flag for popcount.
577.
by dzaima 2y ago
Of course, this just moves the safety question from a javascript-specific JIT to the Truffle JIT compiler and the partial evaluator. This can have some benefits (only one JIT to improve/fix across many languages), but can still have sa
578.
by dzaima 2y ago
Indeed Zen 4 splits uops just as it passes them to pipes, but Zen 4 is already doing that, adding more ports doesn't mean you can do it twice (without, like, making those ports 128-bit (thus not gaining any throughput), or making a new
579.
by dzaima 2y ago
If those could be fed equally well (i.e. doubled decode width, reorder buffer sizes, register file ports), not much would be different, of course, but, from what I understand, that's significantly more expensive (given that the complex
580.
by dzaima 2y ago
Yeah, it's certainly possible that it's not double-pumping. Should be roughly possible to test via comparing latency upon inserting a vandpd between two vpermd's (though then there are questions about bypass networks; and of
581.
by dzaima 2y ago
Almost certainly Zen 5 won't have single-cycle FP latency (I haven't heard of anything doing such even for scalar at modern clock rates (though maybe that does exist somewhere); AMD, Intel, and Apple all currently have 3- or 4-cyc
582.
by dzaima 2y ago
More importantly for the "2 cycles" question, Zen 4 can get one cycle latency for double-pumped 512-bit ops (for the ops where that's reasonable, i.e. basic integer/bitwise arith). Having all 512-bit pipes would still
583.
by dzaima 2y ago
You can 'apt install apl' for GNU APL. Most open-source array languages though either have very few users, and/or are moving quite fast and thus an apt-packaged version would likely be rather out-of-date quite basically alway
584.
by dzaima 2y ago
Ah, the -Warray-bounds-pointer-arithmetic warning is actually just about the pointer addition; thus even that doesn't warn on *(x+10) on the 10-element array, as the construction of the past-the-end pointer is still valid, and seemingl
585.
by dzaima 2y ago
For what it's worth, with clang you can avoid the no-NaNs-or-infinities problem by using '-fassociative-math -fno-signed-zeros' instead of '-ffast-math'.
586.
by dzaima 2y ago
I mean in the case of an array type that tracks its length at runtime. Take: typedef struct { uint32_t arr1_len, arr2_len; int* arr1; int* arr2; } Foo; That's, on a 64-bit system, a 24-byte structure. Wer
587.
by dzaima 2y ago
The compiler cannot change the length field's size if a reference to the array (or a struct where it's contained) is ever passed to an unknown function, as that function has to be able to read the length from memory based just on
588.
by dzaima 2y ago
Clang appears to have -Warray-bounds-pointer-arithmetic for this, though not enabled on -Wall nor -Wextra. (fwiw, clang has -Weverything to turn on literally every warning, including conflicting ones, for finding what flags there are)
589.
by dzaima 2y ago
For the people who actually care about using C, there can be no unified concept of "array". Any single "the system" will just plain and simply be unusable in a good majority of situations. Some people will want to store
590.
by dzaima 2y ago
You can't do 2048 bits of addition in one SVE instruction; not portably, at least (and definitely not on any existing hardware). While the maximum SVE register size is 2048 bits, the minimum is 128 bits, and the hardware chooses the su
591.
by dzaima 2y ago
SVE doesn't need variable-execution-time instructions, outside of perhaps masked load/store, but those are already non-constant. Everything else is just traditional instructions (given that, from the perspective of the hardware, i
592.
by dzaima 2y ago
Don't have an article, but the gist on stacks is that Java still uses the regular architecture stack (rsp on x86, etc) that the FFI'd code will, and on exit to/entry from FFI it'd have to store its stack end/start p
593.
by dzaima 2y ago
Instead of expanding all data to UTF-32 you can expand in chunks of some fixed amount, say, 1024 characters; so memory usage is capped, the UTF-8 unpacking can be unrolled/SIMD whatever, and the thing iterating over codepoints is trivi
594.
by dzaima 2y ago
An all-ASCII fast-path is basically obligatory for anything that cares about performance. And then the "slow path" gets a guarantee that there will be varying-length data, and, as you'll want it to not actually be slow, you&#
595.
by dzaima 2y ago
Integer addition, and indeed pretty much all operations, are also a loops over all bits, LZCNT is in no way at all unique here.
596.
by dzaima 2y ago
Why does an instruction crossing cache lines have anything to do with invalidation/discarding? RISC-V doesn't require instruction cache coherency so the core doesn't have much restriction on behavior if the line was modified,
597.
by dzaima 2y ago
I don't think crossing cache lines is particularly much of a concern? You'll necessarily be fetching the next cache line in the next cycle anyway to decode further instructions (not even an unconditional branch could stop this I&#
598.
by dzaima 2y ago
Mispredict penalties == latency of pipeline. Needing to delay decoding/expansion to after figuring out where instructions actually start will necessarily add a delay of some number of gates (whether or not this ends up in mispredict pe
599.
by dzaima 2y ago
RISC-V already has an extension for simplifying address calculations, Zba, required for RVA23, for doing x*2+y, x*4+y, and x*8+y in a single instruction (sh1add/sh2add/sh3add; these don't have compressed variants, so always 4
600.
by dzaima 2y ago
The compiler can still do optimizations on intrinsics - clang passes most through its regular optimizations, so you get things like loop unrolling, CSE (quite powerful if you have multiple invocations of the same SIMD thing, deduplicating c

More ›