Top
Best
New

Posted by yurivish 11 hours ago

Platform-independent SIMD in Go(go.dev)
331 points | 124 commentspage 2
rcarmo 4 hours ago|
I am using Go assembly for SIMD very heavily in https://github.com/rcarmo/go-pherence, this is just icing on the cake.
vlovich123 8 hours ago||
> 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.

Scaevolus 8 hours ago|
It creates multiple versions of functions referencing SIMD and lifts the dispatch switching cost to their callers.

> The AST rewrite creates multiple specialized copies of functions, variables, and types that mention simd types, where simd types are replaced with references to size-specialized types in simd/internal/bridge. Each of these bridge types is defined as an archsimd type, but with a restricted set of methods. The specialized functions, variables, and types acquire a suffix of the form @simdNNN, where NNN is either a vector length (128, 256, or 512) or 0, indicating emulation. Functions that mention simd internally, but not in their signature, are converted to wrappers that switch on the SIMD level detected at program start, and call the appropriate specialized version of that function. Specialized functions call other specialized functions directly without dispatch overhead (and perhaps with inlining). This rewrite strategy was chosen as a compromise between code duplication and SIMD performance; the overhead is hoisted as high as necessary to avoid dispatch within SIMD computations, but not higher. If SIMD dispatch appears “too low” in a computation, a gratuitous mention of a simd type will move it upwards, as in this example:

keel_dev 6 hours ago||
Question on the multi-versioning approach: if the AST rewrite creates N specialized copies of every function that mentions the SIMD types, doesn't binary size scale with the number of SIMD-touching functions? For generic hot paths (helpers parameterized over vector widths, instantiated across many call sites) that could multiply code size noticeably. Is there dedup when two specialized copies would be identical, or has anyone measured the binary-size cost on a real codebase?
physicsguy 10 hours ago||
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.

typical182 9 hours ago||
FWIW, there is some pretty substantial autovectorization work that is already in-flight for the Go compiler.

There's a CL stack here:

https://go.dev/cl/791740

It's hard to make predictions with an open source project, but my personal guess is some flavor of it will land (including it is already demonstrating good results without an enormous level of code complexity in the compiler and without overly slowing down compile speeds), but I guess we'll see.

It's being driven by an external contributor who has landed some good changes in the past to the Go compiler. (I think the autovectorization work might be part of their PhD or other academic research, but not sure.)

tgv 10 hours ago|||
As a first step, it might be possible to write a linter rule that rewrites suitable numeric loops to SIMD. There are already rules to rewrite several loop types, so that should be doable.
pjmlp 9 hours ago||
The poor Assembler and the unsafe package forgotten in the corner.

While reaching out to CGO is the easier way, it doesn't mean it is the only tool available in Go.

fatty_patty89 9 hours ago||
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
victorbjorklund 8 hours ago||
Why is that the case? I don’t know low level programming so why is Go limited in interop with C?
fatty_patty89 7 hours ago||
its not limited but it has overhead because of the memory model of go doesnt match the C one so there has to be some sort of rerodering being done, that's what i understood atleast, and theres also the go concurrency
pjmlp 7 hours ago||
Use Assembly instead of CGO, isn't that scary, back in the 8 bit days we were coding Assembly aged 10, on our Spectrum, C64, Atari, Apple, Acorn, MSX,....
metaltyphoon 4 hours ago||
For God sake, add a syntax highlighting on the official page! Otherwise this is awesome
watermelon0 3 hours ago|
Rob Pike seems to dislike syntax highlighting:

> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.

https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

He is definitely not alone in thinking this, for example (but for different reasons): https://www.linusakesson.net/programming/syntaxhighlighting/

genxy 2 hours ago|||
I like Linus's work, but that post smells of rotting strawmen. All the examples look manipulated into throwing the opposition under the bus.
metaltyphoon 2 hours ago||||
Not convinced at all by these reasons. Rob Pike has long stepped down from the Go team so it shouldn't matter? This is a website not a language change.
applfanboysbgon 34 minutes ago|||
Wow, that second link does exactly what I do when I'm talking to people about skittle highlighting; demonstrating a skittle highlighted snippet of prose to show how absolutely harmful it is. I only started doing that maybe three years ago, so they've got me beat by 15 years or so! Glad I'm not alone on this crusade, at least. It is genuinely my belief that skittles have cost humankind millions of manhours of productivity, at minimum.
sharktheone 6 hours ago||
I hope portable simd will be stabilized some time in rust :/
karolist 9 hours ago||
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 4 hours ago||
How many "functions" compile to movd?
shevy-java 6 hours ago||
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.
adeptima 3 hours ago|
I personally use both, and keep using both. There are much more Golang job in the market now. Noone planning to ditch Go in my network or unhappy with it. Highload E-commerce, logistics, etc are way easier to write in Go IMHO.

Discover a very good niche for Rust - geo spatial analytics. Would not do it Go or Python. LLMs gave a huge boost to Rust too. Claude produce a very high code ... if designed right. Lot of feature complete libraries now.

Both will do fine

jessechili 4 hours ago|
[flagged]
More comments...