New blog series: @folkertdev shows how we use SIMD in the zlib-rs project.

SIMD is crucial to good performance, but learning how to use it can be daunting. In this series we'll show concrete examples of using SIMD in a real world project.

Part 1 explains how the compiler already uses SIMD for us, how to evaluate whether it's doing a good job, and how to use a more optimal version when the current CPU supports it.

https://tweedegolf.nl/en/blog/153/simd-in-zlib-rs-part-1-autovectorization-and-target-features

@trifectatech

While implementing complex numbers for #simd I tripped over failures wrt. negative zero. After multiple re-readings of C23 Annex G and considering the meaning of infinite infinities on a 2D plane (with zeros simply being their inverse) I believe #C and #CPlusPlus should ignore the sign of zeros and infinities in their x+iy representations of complex numbers. https://compiler-explorer.com/z/YavE4MnMj provides some motivation.
Am I missing something?

Ah, the classic tale of a coder thinking #SIMD would make their code fly , only to discover it trips over its own feet . Our hero's memory seems as patchy as their #benchmarks, but fear not, the valuable lesson here is clear: #optimization is just a synonym for #headache.
https://genna.win/blog/convolution-simd/ #coding #woes #lessons #HackerNews #ngated

Unlocking the Power of Assembly Language in FFmpeg: A Deep Dive into SIMD Programming

FFmpeg's assembly language lessons reveal the intricacies of SIMD programming, offering developers a chance to optimize multimedia processing. This article explores the significance of assembly langua...

https://news.lavx.hu/article/unlocking-the-power-of-assembly-language-in-ffmpeg-a-deep-dive-into-simd-programming

Faster Integer Division with Floating Point - Multiplication on a common microcontroller is easy. But division is much more diff... - https://hackaday.com/2024/12/22/faster-integer-division-with-floating-point/ #softwaredevelopment #softwarehacks #optimization #assembly #avx-512 #x86_64 #simd #x86

Channeling my inner @shafik, assuming a standard, compliant #riscv processor, what kind of float instructions can be executed on the vector unit of a processor that advertises

"RV32IMFDZve64f"

#HPC #IEEE754 #SIMD #RISCV #RVV

https://github.com/riscvarchive/riscv-v-spec/releases/download/v1.0/riscv-v-spec-1.0.pdf

Days since burned by the #RVV Spec: 0

Turns out the 32 bit version of RVV doesn’t mandate the normal f and D data type extensions unlike the 64 bit version -.-

For the #SIMD nerds, a fun discussion of algorithm design on fixed vs variable length vector extensions: https://bsky.app/profile/falvyu.bsky.social/post/3lcm2ulsphs2y

Hey friends!
For folks interested in #RISCV, and especially #RVV, here's some information on the #tenstorrent in house designed CPU!

High level, vector is 2x256, full RVV1.0 as well as a fair few of the optional extras to RVV1.0!

Phoronix article here: https://www.phoronix.com/news/LLVM-20-Tenstorrent-Ascalon

LLVM patches here: https://github.com/llvm/llvm-project/pull/115100

One Pager: https://cdn.sanity.io/files/jpb4ed5r/production/6a28f7d59b6d1300fccdbdd394e192a4fd5f54c6.pdf

C++26 will have data-parallel types (or std::simd as it came to be known; unless we rename it next meeting — don't settle in for the name just yet) #cpp #cplusplus #cpp26 #simd

#simd

there's this trick i randomly found a few years ago and i've been wondering if there's a name for it or if other people have done this before

```
for enforcing floating point determinism with realigned buffers

if we have
x x x 0 1 2 3 4 5 6 7 x x x

where x is the identity for my operation, and our operation is commutative (not necessarily associative)

then adding x padding doesn't affect the result as long as we do a tree reduction at the end

e.g.

accumulate in register: v = 0+4 1+5 2+6 3+7

tree reduction step 0: (0+4)+(2+6) (1+5)+(3+7)
tree reduction step 1: ((0+4)+(2+6)) + ((1+5)+(3+7))

if we add padding (e.g., by realigning the buffer and using a masked load)

accumulate in register: v = x+1+5 x+2+6 x+3+7 0+4+x

tree reduction step 0: (1+5)+(3+7) (0+4)+(2+6)
tree reduction step 1: ((1+5)+(3+7)) + ((0+4)+(2+6))

commuting the elements shows us that this is the exact same result as the previous one, so the bit pattern of the final result is unaffected (modulo signed zero, nan, etc)
```

HW implementation people: is #RVV as bad to implement if it’s purely in order?

My intuition is you’re still going to have trouble around LMUL + gather, but that seems much easier without tracking implied state/register renaming across OoO

Yesterday, one year ago... (Still wondering how many people actually have read or tried out any of these)

https://mastodon.thi.ng/@toxi/111348591236791838

A real #SIMD #ISA on #riscv?

Pete Crawley, AKA Corsix, deep dives the Tenstorrent wormhole Tensix vector unit!

https://www.corsix.org/content/tt-wh-part6

Hey friends! Looking for clarity on the topic of the matrix extensions to #RISCV.

I’ve seen a lot of proposals for specs around, but is there an actual, in progress, official *spec* that someone can point me towards?

Jeroen Koekkoek, one of our lead developers, has collaborated with @lemire to create a blazingly fast #DNS zone file parser that is now part of our authoritative nameserver NSD.

They have now published a paper outlining how they enhanced parsing throughput using data parallelism, specifically Single Instruction Multiple Data (#SIMD) instructions available on commodity processors. #programming https://www.authorea.com/1222979

I feel like I’m missing something with how the overlap of RV extensions is done, namely the implied support of types in #RVV.

Ex: Given a chip that supports rv64gfdv, does that imply that both the scalar and vector units *must* support FP32 and FP64?

Or would an implementation that has FP64 on the scalar units only, but FP32 on both the scalar and the vector units, be valid?

Namely the passage I’m uncertain of is https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#13-vector-floating-point-instructions

Clang/LLVM friends, trying to understand *why* Clang (18) doesn't see through what seems to me like an obvious optimization.

#compiler_explorer link here, explanation of what I don't understand follows:
https://godbolt.org/z/j8WqsMjb6

Going through Hackers delight and doing some of the dirt simple exercises, I dumped the assembly for Chapter 1 exercise 2 "loop that goes from 1 to 0xFFFFFFFF". (changed to not fault in CE)

(continues in next post, but putting hashtags here)