camel-cdr

8 ms·

91.
by camel-cdr 6mo ago
Thanks I've been doing dumb sudo sh -c ... stuff before.
92.
by camel-cdr 6mo ago
The lines __m512i vx = _mm512_set1_epi64(static_cast<long long>(x)); __m512i vk = _mm512_load_si512(reinterpret_cast<const __m512i*>(base)); __mmask8 m = _mm512_cmp_epu64_mask(vx, vk, _MM_CMPINT_GE); return
93.
by camel-cdr 6mo ago
> good luck parsing through 100 different "performance optimization manuals" from 100 different companies This would be a problem for any ISA with multiple/many vendors.
94.
by camel-cdr 7mo ago
Idk, it seems to me like the Rivos people are still doing their RISC-V CPU work.
95.
by camel-cdr 7mo ago
Oh, cool, I didn't see them on the website. ( https://labs.scaleway.com/en/em-rv1/ )
96.
by camel-cdr 7mo ago
Sadly still on quite old hardware, with no RVV. Hopefully scaleway will have some newer servers in the future and this can be simply updated to the new devices.
97.
by camel-cdr 7mo ago
K&R syntax is -1 char, if you are in C: double solve(double a,double b,double c,double d){return a+b+c+d;} double solve(double a...){return a+1[&a]+2[&a]+3[&a];} double solve(a,b,c,d)double a,c,b,d;{return a+b+
98.
by camel-cdr 7mo ago
LLVM mostly uses size_t like most C/C++ programs, which either use size_t or int for everything, both of which are handled well by RISC-V. > Maybe looking at libgmp could be interesting, though I suspect absolute numbers will not be
99.
by camel-cdr 7mo ago
> For example, should we use vrgather (with what LMUL), or interesting workarounds such as widening+slide1, to implement a basic operation such as interleaving two vectors? Use Zvzip, in the mean time: zip: vwmaccu.vx(vwaddu.vv(a, b), -1
100.
by camel-cdr 7mo ago
OK, look. Since my previous attempt to measure the impact of trap on signed overflow didn't seem to have moved your position one bit, I thought I'd give it a go in the most representable way I could think of: I build the same vers
101.
by camel-cdr 7mo ago
Exactly, I 100% agree, and IMO toolchains should default to assuming fast misaligned load/store for RISC-V. However, the spec has the explicit note: > Even though mandated, misaligned loads and stores might execute extremely slowly.
102.
by camel-cdr 7mo ago
The cursed thing is that RVA23 does basically guarantees that `vle8.v` + `vmv.x.s` on misaligned addresses is fast.
103.
by camel-cdr 7mo ago
x86 is a lot easier to JIT to Arm or RISC-V though, because it has fewer registers.
104.
RISC-V Integrated Matrix Extension Release for Internal Review(github.com)
5 points by camel-cdr 7mo ago|0 comments
105.
by camel-cdr 7mo ago
Signend 64-bit is the worst case. When I tried to enable overflow checking thr overhead of RISC-V and Arm was comparable: https://news.ycombinator.com/item?id=46588159#46668916
106.
Felix86 26.03: AVX, AVX2, BMI1 and F16C Support(felix86.com)
3 points by camel-cdr 7mo ago|0 comments
107.
by camel-cdr 8mo ago
Should've probably been the link to the actual Ubuntu blog: https://ubuntu.com//blog/canonical-and-ubuntu-risc-v-a-2025-...
108.
by camel-cdr 8mo ago
Agreed, however, I'm quite sure 25,000 lines translated in "multiple months" is very "slow", for a naive translation between languages as similar as C++ and Rust.
109.
Visualizing the RISC-V Instruction Set(gist.github.com)
3 points by camel-cdr 8mo ago|0 comments
110.
by camel-cdr 8mo ago
here you go: https://gist.github.com/camel-cdr/bd5b197ab140ad6df259916df1...
111.
by camel-cdr 8mo ago
> Kind of, but the part which looks particularly annoying is that you can't put variable-width vectors on the stack or pass them around as values in most languages, because they aren't equipped to handle types with unknown size
112.
by camel-cdr 8mo ago
The 1024-bit RVV cores in the K3 are mostly that size to feed a matmul engine. While the vector registers are 1024-bit, the two exexution units are only 256-bit wide. The main cores in the K3 have 256-bit vectors with two 128-bit wide exexu
113.
by camel-cdr 8mo ago
The problem with SVE is that ARM vendors need to make NEON as fast as possible to stay competitive, so there is little incentive to implement SVE with wider vectors. Graviton3 has 256-bit SVE vector registers but only four 128-bit SIMD exec
114.
by camel-cdr 8mo ago
> SVE was supposed to be the next step for ARM SIMD, but they went all-in on runtime variable width vectors and that paradigm is still really struggling to get any traction on the software side. You can treat both SVE and RVV as a regula
115.
by camel-cdr 8mo ago
That was a bit overblown, due to my lack of knowlage about MMX. It has a lot more things than MMX. But the core idea behind the P extension was to reuse the GPRs to do SIMD operations with little additional implementation cost. The spec is
116.
by camel-cdr 8mo ago
The name, yes, but going by name is a bad idea as the V in AVX also stands for Vector. BTW, you'll be disappointed if you think of the P extension as something like SSE/AVX. The target for it is way lower power/perf, like a s
117.
by camel-cdr 8mo ago
I like this document, but it seems to be written with a very specific implementation in mind. You can implement both regular SIMD ISAs and scalable SIMD/Vector ISAs in a "Vector processor" style and both in a regular SIMD sty
118.
by camel-cdr 9mo ago
No, the 2.5GHz are for SFX4. Atlantis is on TSMC 12nm and (as I learned yesterday) will run at about 1.5GHz: https://cdn.discordapp.com/attachments/1061659786023813170/1... So Ascalon should have M1 IPC, at half t
119.
by camel-cdr 9mo ago
There isn't much to tune in some, e.g. the clang benchmark. We know that many of the benchmarks already have RVV support (compare BPI-F3 results between versions) and three are still missing RVV support. I think the optimized score wou
120.
by camel-cdr 9mo ago
can you share the code?

More ›