Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
dzaima
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
51 ms
·
751.
▲
by
dzaima
3y ago
" https://github.com./a/b " or " https://www.github.com/a/b " also work as "workarounds". But it is incredibly stupid & annoying that it doesn't even go away aft
752.
▲
by
dzaima
3y ago
If 99.99% of people have patched their systems against Spectre, there's no reason for anyone to bother exploiting it. But if noone patched their systems, it'd obviously be exploited far and wide because it demonstrably can be.
753.
▲
by
dzaima
3y ago
RVV has masking for everything (masks being stored as packed bits in a vector register), memory gather & scatter, compress (& easily emulatable expand via an instruction that expands 0,1,2,3,… by which you can then shuffle), and in
754.
▲
by
dzaima
3y ago
You're not wrong though; see.. https://mlochbaum.github.io/BQN/tutorial/variable.html#modif... I guess
755.
▲
by
dzaima
3y ago
The P extension is quite "small" though - it works in the regular 32/64-bit x1-x31 GPRs, which is also pretty far from traditional SIMD.
756.
▲
by
dzaima
3y ago
rvv1.0 is frozen, and ffmpeg does contain some usage of it: https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/libavcod...
757.
▲
by
dzaima
3y ago
Doesn't seem like it'd be that difficult to make the change the other direction, i.e. keep endbr64 as-is as the default case, but if there's a direct jump/call to anywhere that starts with endbr64, offset the immediate b
758.
▲
by
dzaima
3y ago
Those might be "cheap" to tack onto an x86 core where there already is a ton of microcoding infrastructure, but on RISC-V that just won't the the case often. It could make sense to have an extension for it, but not really any
759.
▲
by
dzaima
3y ago
> Is the addition done by itself, so it costs 1 clock cycle? Is it merged into some complex operation so the net cost is less than 1 cycle? Is it completely optimized away at compile time, so it's infinitely faster? Those are generi
760.
▲
by
dzaima
3y ago
Right, that's definitely quite a strong point against the C operator-function separation. There can be a good argument made for just not providing unavailable operations as operators. But, still, x/y won't touch any of your m
761.
▲
by
dzaima
3y ago
If I see `x+y` in C, I know 100% that it'll be ~0-1 instructions, O(1), and will have the lowest latency & highest throughput that a thing can have, i.e. basically completely ignorable for figuring out the perf of a piece of code,
762.
▲
by
dzaima
3y ago
If you want truly high-performance, architecture-generic SIMD won't get you particularly far though - the utter mess of things that x86-64 does and doesn't support is an utter mess, and doing things well across fixed-width and var
763.
▲
by
dzaima
3y ago
Option 1 only works if there is a sensible unified interface, and if you feel like spending the time making that for what could be just one line per target. And it just won't work for things that don't really "have an interfa
764.
▲
by
dzaima
3y ago
More importantly, it's also the abstraction that the CPU itself provides, not C. It'd be neat to be able to control all those things, but that's largely impossible, so I'll take the next best thing.
765.
▲
by
dzaima
3y ago
> cryptic "undefined behaviors" It's not really that cryptic (aside from like strict aliasing, but -fno-strict-aliasing). There's some UB that might be considered unnecessary/too strict, but it still makes sense
766.
▲
by
dzaima
3y ago
Note, that's only ARMv7; ARMv8 dropped most of the conditionally executed instruction stuff. And so it isn't even jumps that's fast on ARMv7, it's specifically cases that can be (and are) converted to predicated instrs;
767.
▲
by
dzaima
3y ago
The memcpy doesn't use a vlmax, it uses a hand-chosen vl. The load won't fault on any elements not loaded (here, elements past the vl), so the memcpy is fine as it only loads items it'll definitely need, whereas your original
768.
▲
by
dzaima
3y ago
Go ahead! I'm not much of a web dev either, but decided to struggle through it to, mainly, just have better searching. (originally for intel & ARM intrinsics, which are also available if downloaded offline)
769.
▲
by
dzaima
3y ago
You'd probably want to have a new __riscv_vsetvlmax_e8m8 at the start of each loop iteration, as otherwise an earlier iteration could cut off the vl (e.g. page unloaded by the OS), and thus the loop continues with the truncated vl. The
770.
▲
by
dzaima
3y ago
To be fully correct, you'd need the load to be a fault-only-first load (which rvv does have), otherwise that could fail if the null byte was just before the end of allocated memory.
771.
▲
by
dzaima
3y ago
As an extra note on big/little cores - instead of having the small core break up ops, you could possibly instead have the big core handle higher LMUL natively. Requires code to use said higher LMUL (currently, clang defaults to LMUL 2,
772.
▲
by
dzaima
3y ago
> An algorithm which works well for hardware implementing 128-bit vectors might be quite bad for one implementing 2048-bit vectors Yeah, that's definitely a concern. I do wish that RVV had some built-in way to cap the width in a req
773.
▲
by
dzaima
3y ago
At the very least, that's an issue that GMP or other projects shouldn't have to worry about. There are many options - you could manually cache things somewhere or pack in the dependencies in the repo. Or, maybe, in a world that wa
774.
▲
by
dzaima
3y ago
What GitHub is effectively doing is providing free DDoS hardware and lots of it, as far as the receiving end is concerned. I don't think GitHub should particularly be "under fire" for this, but it's still very not nice t
775.
▲
by
dzaima
3y ago
That's a bit dramatic. Yes, RVV does add to the problem of the same binary running differently on different implementations, but it's not like that doesn't already happen a lot. The main thing that sucks about it imo is that
776.
▲
by
dzaima
3y ago
"posts" on the sidebar links to https://moonbaseotago.github.io/posts.html , which is a page with just the dates & titles.
777.
▲
by
dzaima
3y ago
That's about the number in the post here. The readme is better at this, as it does actually mention std::sort, whereas here it's just "Intel's sort and ours can be about 10x as fast as scalar.". (not that I expect e
778.
▲
by
dzaima
3y ago
"can be", if taken as modestly as needed for it to be correct here, is pretty much a completely useless statement. Of course [insert modern sort] is [a ton] faster than [some other unspecified old sort that might not even be targe
779.
▲
by
dzaima
3y ago
Traditionally, autovectorization works by doing some prefix of the array vectorized, and the remaining elements with a scalar loop, e.g. 108 items may be processed by 6 iterations of a vectorized loop that processes 16 elements at a time, a
780.
▲
by
dzaima
3y ago
Direct function calls are usually done relative to the program counter (pc in auipc). So you get 32 bits of displacement , which is fine as long as your code is less than 4GB, and you get position-independent code for free. This is the sam
More ›