Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
52 ms
·
661.
▲
by
dzaima
3y ago
Another different shift implementation is in ARM NEON, where, for a non-constant shift amount, there's only a shift-left, and that with a negative shift amount gets you right shift; thus, were it forced to choose only one behavior, eit
662.
▲
by
dzaima
3y ago
C++ doesn't even define it as that; it's actually just undefined behavior to shift by any amount greater than or equal to the width!
663.
▲
by
dzaima
3y ago
Isn't shorter path length the goal here? And ARM is better by both those metrics. Am I misunderstanding something? ARM of course would also benefit from fusion too; but camel-cdr's mention of it being only rv64g is a pretty signif
664.
▲
by
dzaima
3y ago
Dunno about "great" - "For 6 out of 10 mini-app+compiler pairs, Arm has a shorter path length, with the overall average difference when weighting each benchmark equally being 2.3% longer for RISC-V."
665.
▲
by
dzaima
3y ago
That's the same approach that gets you from 2 to 1 clobbered registers for stores, no? i.e. usually possible, but needs compiler participation; if assuming the compiler will optimize load register usage properly, it shouldn't have
666.
▲
by
dzaima
3y ago
Minor note - RISC-V's Zba (included in RVA22, which afaik is set to be the baseline requirement for Android) has sh2add for a combined x+y*4, getting that store down to two instructions (testable with -march=rv64gczba); doesn't af
667.
▲
by
dzaima
3y ago
For my solution ( https://github.com/dzaima/1brc , uses jdk.incubator.vector significantly), switching all array reads/writes to identical Unsafe ones results in the solution running ~100x slower , so there's
668.
▲
by
dzaima
3y ago
I believe J doesn't have any optimizations specifically for the problem of large temporary arrays (not to say that such can't exist, but I don't think anyone's written such yet). With multiple temporary operations, each
669.
▲
by
dzaima
3y ago
While RVV still makes for a good target for arraylang implementations, RVV isn't really much closer to arraylangs than AVX-512, or really any SIMD if you squint hard enough (the scalability of RVV/SVE is unrelated as you still nee
670.
▲
by
dzaima
3y ago
There are a couple options for working around this. Lazy evaluation is indeed one option (e.g. Kap[0] uses it). Another clear option is loop-fusing the entire body together such that there are no temporary arrays. Then there's the slig
671.
▲
by
dzaima
3y ago
Similar thing presumably happens on GitHub commit pages - at the bottom there's a "You’re not receiving notifications from this thread." (or a different message if you have, presumably) that only loads once you've scroll
672.
▲
by
dzaima
3y ago
Unfortunately, we can't change the past, and seemingly in the past it wasn't worth it to have a fast One True memcpy (and perhaps to a decent extent still isn't). I'm still typing this on a Haswell CPU, which don't
673.
▲
by
dzaima
3y ago
Some quick searching gives that FSRM is used for at least 128 bytes or so (ERMS for ≥~2048 bytes for reference); in base x86 (i.e. SSE2) that's 8 loads & 8 stores, ~62 bytes of code. At that point calling into a library function is
674.
▲
by
dzaima
3y ago
The kind of things you can use direct SIMD for is a reasonably-different space than array languages; while some things can translate reasonably, APL-likes get much less pretty on operations where elements don't have homogeneous meaning
675.
▲
by
dzaima
3y ago
And so Java effectively mandates at least max(32, size of Object)-bit atomic writes, while C can trivially run on 16-bit systems. I don't know if anyone's running multi-threaded software on such, but having a completely arbitrary
676.
▲
by
dzaima
3y ago
Far from the full story, but a note is that Java has the nice property of all possible single-operation writes being ≤8 bytes, all aligned if the VM so wants (byte, char/short, int, long, and Object are all the possible writes), wherea
677.
▲
by
dzaima
3y ago
Small note - while the compiler wasn't able to optimize that specific popcount implementation to a single instruction, it can for some other implementations, though it's of course very picky: https://godbolt.org/z&
678.
▲
by
dzaima
3y ago
I'd perhaps say that security can be a good idea, but it needs to be done well for it to be so. And not at all implementing a potentially-abusable feature, while counting as "secure", is absolutely not doing it well.
679.
▲
by
dzaima
3y ago
> FWIW all the reasons seem like an aversion to complying with how Wayland works. The absolute last thing you should want from a platform is to have to "comply" with its weird decisions and assumptions on what people will or
680.
▲
by
dzaima
3y ago
You don't make multiple forks of a project if you want to PR multiple separate changes though (github doesn't even allow it). And, on top of that, last I heard, forks in github are actually implemented as git branches. :)
681.
▲
by
dzaima
3y ago
QEMU's RVV is all ahead-of-time-compiled scalar loops when I looked at it a couple months ago, so the results would be very bad (worse than scalar equivalents). Even x86-64 SSE2 on x86-64 is scalar ahead-of-time-compiled helpers.
682.
▲
by
dzaima
3y ago
On vtype/setvl: in the RISC-V V extension (aka RVV / Vector (≈SIMD)), due to the 32-bit instruction length, there's a separate instruction that does some configuration (operated-on element size, register group size, masked-of
683.
▲
by
dzaima
3y ago
I dearly hope that there isn't much reselling of hardware keys/wallets going on, that's indeed a nice and simple recipe for disasters.
684.
▲
by
dzaima
3y ago
I don't really see that being a feasible attack vector for any attacker - you can't really control who's gonna buy the tampered-with thing, so it can't be a targeted attack (unless the buyers are all high-value victims,
685.
▲
by
dzaima
3y ago
Ah right, Firefox does have a nice option for this. I happened to check Chromium on desktop, but Firefox on Android (which were the browsers I had open already), which doesn't have this option.
686.
▲
by
dzaima
3y ago
There's the counter-issue of trying to search for some specific character, and instead matching the generic one. For example, searching "ā" on chrome or firefox finds all "a"s, which is extremely annoying if there&#
687.
▲
by
dzaima
3y ago
There are extensions for chrome and firefox[0] that can allow for continued scrolling by scroll wheel to exponentionally (as in, actually exponential) speed up. With this, I pretty much never use the scrollbar UI element as an input. [0]:
688.
▲
by
dzaima
3y ago
Again, I pretty much agree. WHILELT makes RVV-equivalent things trivial, but it's just a data→data instruction that could be done in AVX-512 too, as it's just a scalar (1<<n)-1, so the SVE2 & AVX separation in snvzz'
689.
▲
by
dzaima
3y ago
Yes, I agree that VL isn't meaningfully distinct from masking as I noted in a sibling reply; regardless, some definitions of SIMD vs vector rely on it, e.g. wikipedia: https://en.wikipedia.org/wiki/Vector_processor
690.
▲
by
dzaima
3y ago
Furthermore, IMO calling an ISA only one of 'vector' or 'SIMD' based on whether it has VL doesn't make sense - semantically, VL is a subset of masking (if you want VL & a mask, just and them), whether hardware w
More ›