Portable SIMD is ~11% slower than non-portable SIMD in this case, but both are ~5x faster than non-SIMD.
mshockwave
Just want to say among many portable SIMD solutions I’ve seen recently (e.g. Fearless SIMD), this is the first that makes non-fixed vectors like SVE and RISC-V vector (RVV) easier to support. Glad to see they made this decision
show comments
beached_whale
C++ is getting std::simd in the latest version and I am all aboard writing the vectorization with the least amount of intrinsic builtins I am able to. Even if not optimal, it's far better than the scalar ops.
show comments
qprofyeh
This feature opens many doors for optimizing low-level performance in Go projects, that are already running multicore. IIRC there aren’t a lot of languages with built-in std lib support for SIMD and variants. Love the way Go is trying new stuff lately.
show comments
sixdimensional
I did some testing with the experimental SIMD on a project I was doing to make speech-to-text and text-to-speech models run natively in Go (with CGO_ENABLED=0, so no C depenencies), and testing non-SIMD w/ SIMD.
I don't have formal benchmarks for that, but I can anecdotally say the SIMD work made a measurable improvement in the performance of the calculations vs. just plain Go. I'm very optimistic about how these improvements will help make the Go runtime an even better target for more of these types of work going forward, especially since it is cross-platform.
u8
This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
show comments
vira28
This will welcome more database/warehouses to be written in Go.
Very neat, and comes pretty close to how Mojo handles portable SIMD.
It's great to see two of my favorite languages finally making SIMD easy to use. It's such low-hanging fruit for performance, yet somehow languages have ignored it for years. Portable SIMD, even with some performance penalty, still beats scalar computation whenever vector operations are needed. Yet language implementations always seemed to assume that hardware-specific SIMD APIs were the only way to go. That did nothing but make SIMD unusable excepting special cases where performance is absolutely critical, rather than just something anyone can use in day to day programming.
ghusbands
> The new simd package hides these differences by removing fixed-size vectors from the type system, and by only supporting those operations that are in the intersection of all the different platforms, and fills gaps in the intersection with efficient emulation in terms of other SIMD instructions.
The intersection would be the operations supported by all platforms and so would not have gaps.
cryptolobster
Curious how much of the emulation ends up in hot paths before SVE and the feature variants land.
> The interface conversion and type switch look like they should be inefficient, but the compiler-side implementation of simd specializes code and optimizes away the type switch.
I don’t understand this - how is it able to if the same go binary might run on unknown types? I’m assuming what it means is that the switch is implemented efficiently due to CPU branch prediction? I know fearless SIMD is doing cool stuff with static dispatch so that the feature set is checked just once at program start - is that what it means it’s doing under the hood? Very unclear.
show comments
physicsguy
Oh this is great, it was one of my biggest bugbears about Go since you almost always have to link C/C++ code to get the appropriate performance.
The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.
show comments
fatty_patty89
The problem with Go isn't performance but with the C/C++ interop overhead, even with the "30% less overhead" from a few updates ago which isnt true for 99% of cases, it isnt enough
show comments
metaltyphoon
For God sake, add a syntax highlighting on the official page! Otherwise this is awesome
show comments
sharktheone
I hope portable simd will be stabilized some time in rust :/
karolist
Already using this for foreground estimation of cutouts in my project, around 30% speedup over non-SIMD, but the algorithm is probably not very optimised yet.
Am4TIfIsER0ppos
How many "functions" compile to movd?
shevy-java
Rust kind of seems to have overtaken Go in momentum recently. I wonder if Go will do well in, say, two years from now on.
show comments
chrisjj
> Go 1.26 and 1.27 include experimental APIs for Single Instruction Multiple Data (SIMD) operations.
You'd think these people would know the meaning of API, no?
https://imjasonh.github.io/playground/palette-swap/ swaps colors in a provided image in wasm, entirely locally in your browser, to benchmark portable SIMD vs non-portable archsimd vs non-SIMD.
Portable SIMD is ~11% slower than non-portable SIMD in this case, but both are ~5x faster than non-SIMD.
Just want to say among many portable SIMD solutions I’ve seen recently (e.g. Fearless SIMD), this is the first that makes non-fixed vectors like SVE and RISC-V vector (RVV) easier to support. Glad to see they made this decision
C++ is getting std::simd in the latest version and I am all aboard writing the vectorization with the least amount of intrinsic builtins I am able to. Even if not optimal, it's far better than the scalar ops.
This feature opens many doors for optimizing low-level performance in Go projects, that are already running multicore. IIRC there aren’t a lot of languages with built-in std lib support for SIMD and variants. Love the way Go is trying new stuff lately.
I did some testing with the experimental SIMD on a project I was doing to make speech-to-text and text-to-speech models run natively in Go (with CGO_ENABLED=0, so no C depenencies), and testing non-SIMD w/ SIMD.
I don't have formal benchmarks for that, but I can anecdotally say the SIMD work made a measurable improvement in the performance of the calculations vs. just plain Go. I'm very optimistic about how these improvements will help make the Go runtime an even better target for more of these types of work going forward, especially since it is cross-platform.
This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
This will welcome more database/warehouses to be written in Go.
Personally I will implement it in https://github.com/viggy28/streambed
Very neat, and comes pretty close to how Mojo handles portable SIMD.
It's great to see two of my favorite languages finally making SIMD easy to use. It's such low-hanging fruit for performance, yet somehow languages have ignored it for years. Portable SIMD, even with some performance penalty, still beats scalar computation whenever vector operations are needed. Yet language implementations always seemed to assume that hardware-specific SIMD APIs were the only way to go. That did nothing but make SIMD unusable excepting special cases where performance is absolutely critical, rather than just something anyone can use in day to day programming.
> The new simd package hides these differences by removing fixed-size vectors from the type system, and by only supporting those operations that are in the intersection of all the different platforms, and fills gaps in the intersection with efficient emulation in terms of other SIMD instructions.
The intersection would be the operations supported by all platforms and so would not have gaps.
Curious how much of the emulation ends up in hot paths before SVE and the feature variants land.
I am using Go assembly for SIMD very heavily in https://github.com/rcarmo/go-pherence, this is just icing on the cake.
> The interface conversion and type switch look like they should be inefficient, but the compiler-side implementation of simd specializes code and optimizes away the type switch.
I don’t understand this - how is it able to if the same go binary might run on unknown types? I’m assuming what it means is that the switch is implemented efficiently due to CPU branch prediction? I know fearless SIMD is doing cool stuff with static dispatch so that the feature set is checked just once at program start - is that what it means it’s doing under the hood? Very unclear.
Oh this is great, it was one of my biggest bugbears about Go since you almost always have to link C/C++ code to get the appropriate performance.
The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.
The problem with Go isn't performance but with the C/C++ interop overhead, even with the "30% less overhead" from a few updates ago which isnt true for 99% of cases, it isnt enough
For God sake, add a syntax highlighting on the official page! Otherwise this is awesome
I hope portable simd will be stabilized some time in rust :/
Already using this for foreground estimation of cutouts in my project, around 30% speedup over non-SIMD, but the algorithm is probably not very optimised yet.
How many "functions" compile to movd?
Rust kind of seems to have overtaken Go in momentum recently. I wonder if Go will do well in, say, two years from now on.
> Go 1.26 and 1.27 include experimental APIs for Single Instruction Multiple Data (SIMD) operations.
You'd think these people would know the meaning of API, no?