sorear[m] changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<dzaima[m]>
re: autovectorization demand - my intuition would be that it's really going the other direction, i.e. people will stop bothering writing assembly/intrinsics, especially with all the different targets (SSE, AVX2, AVX512, NEON, SVE, and now RVV) and with autovectorization being pretty good
<muurkha>
dzaima[m]: those nicks look formatted the same way (and, FWIW, IRSSI doesn't highlight @libera_muurkha:catircservices.org as referring to me)
joev1 has quit [Ping timeout: 272 seconds]
<dzaima[m]>
yeah, I see it in the IRC logs
joev1 has joined #riscv
<dzaima[m]>
muurkha: I guess for now ascii names will have to do (i.e. can't use autocomplete or click on usernames in the log to auto-enter it as that gives the fancy pill which doesn't translate)
shoragan has quit [Quit: quit]
shoragan has joined #riscv
joev1 has quit [Ping timeout: 260 seconds]
joev1 has joined #riscv
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #riscv
<muurkha>
dzaima[m]: I mean, the distribution of CPU time over pieces of code gets more and more skewed as data grows in proportion to processing power
aerkiaga has quit [Ping timeout: 245 seconds]
<muurkha>
which means that today you could reasonably write 99% of your code in something ridiculously inefficient like CPython
<muurkha>
or, if you prefer, OCaml or Typescript
<muurkha>
with a minimally optimizing compiler
<muurkha>
the other 1% (and shrinking) will be faster if you handwrite assembly for it instead of depending on autovectorization
<muurkha>
and the performance gains are large enough for hyperscalers that it pays the salary of the guy writing the assembly
MarvelousWololo has quit [Ping timeout: 264 seconds]
<dzaima[m]>
that's assuming companies bother thinking about whether that'd be worth the salary,.. or, like, bother profiling their code at all
<dzaima[m]>
see: GTA-V O(n^2) JSON parser taking up 70% of the load times
jacklsw has joined #riscv
unsigned has quit [Read error: Connection reset by peer]
aerkiaga has joined #riscv
unsigned has joined #riscv
<dzaima[m]>
there will always be a place for micro-optimizing significantly-used extreme hotspots, but the amount of boring code that noone will bother optimizing is expanding at scary speeds
<dzaima[m]>
I don't really know if autovectorization can even help such often, but given the volume it certainly will in a lot of cases
aerkiaga has quit [Remote host closed the connection]
<Danidada>
Great, has someone tried compiling and running it on QEMU?
<palmer>
yes
<Danidada>
thanks, I'll give it a try then
Tenkawa has joined #riscv
vagrantc has quit [Quit: leaving]
flip768 is now known as flip214
awita has joined #riscv
<courmisch>
sorear: https://pastebin.com/JCg9Br4t <- do you see something I don't see there. It's (slightly) slower than scalar equivalent (regardless of LMUL)
<courmisch>
the only explanation I have is that vfredusum just sucks on that IP
<courmisch>
which is pretty sad. I would understand the ordered version being slow, but the unordered one...
<sorear>
the unordered one is still going to be a bit slower than a normal addition, partly because it has to do log2(VL) levels of reductions, and partly because it can't be combined into a vfmacc
<sorear>
i think the usual approach for unordered reductions is to have an entire vector's worth of reduction variables, then combine them into a scalar at the end
<courmisch>
scalar should do N additions
<sorear>
wdym
<courmisch>
so I should take the reduction out of the loop?
<courmisch>
that will cause some border effects but fair enough
<sorear>
yes. border effects?
<courmisch>
well the last iteration won't fill a whole vector
<courmisch>
I suppose that would be one rate use case for tail undisturbed
<courmisch>
rare*
dani_ has joined #riscv
Danidada has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]