Platform-independent SIMD in Go
go.dev
go.dev
Portable SIMD is ~11% slower than non-portable SIMD in this case, but both are ~5x faster than non-SIMD.
I'm grateful that Go a non-proprietary language offers these features.
So yeah, also appreciate having Go in the group instead of manually having to write Assembly.
However not many languages adopt ways to manually write SIMD, because most of us have no idea how to write good SIMD code in first place, I surely don't.
I work for a C++ timeseries database startup that leverages SIMD about as much as we possibly can, and except for some extremely rare places we just use libraries.
However even then, it depends on how the libraries API surface looks like.
"CGO 2022 Keynote: Compiler 2.0"
Unless this was tongue in cheek, because this is in fact a problem with AI that it degrades your codebase in these types of ways.
[0] Mitchell Hashimoto: "Everyone Should Know SIMD" https://mitchellh.com/writing/everyone-should-know-simd
Mojo has an even more portable simd[1] type that isn't just generic over length but also over type. In my opinion it is almost always better to specialize for each platform and use portable implementation as fallback. It's a shame that just very few languages support Zig-like comptime, because it would be excellent for specializations without introducing runtime penalties.
Or, put a dynamic factor into your vector size and design everything around it. Such that every platforms can plug in their own factor and _scale_ the size of vectors. This is basically what LLVM IR does for SVE and RVV: `<vscale x 4 x i32>` where vscale is the said dynamic factor. Though the exact value of vscale is only known during runtime, it doesn't matter -- we still can design compiler optimizations and lowering around it. The generated binaries can then be portable across platforms with different vscale values.
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.
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.
So whats your point here? Haskell?
Wow my dude, let's talk about YOUR engineering understanding hahaha.
Go talk to your LLM, you better have to...
Race conditions in general are another matter, and aren’t generally considered a requirement (though you can certainly create nasty bugs).
Thread a = new Thread(() -> x++);
Thread b = new Thread(() -> x++);
a.start();
b.start();Go does not have that.
(Of course also Java may suffer from memory safety issues on system boundaries to unsafe code and due to JVM bugs.)
> I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race.
And from tptacek in that same discussion [2]:
> The fact is that Go doesn't admit memory corruption vulnerabilities, and the way you know that is the fact that there are practically zero exploits for memory corruption vulnerabilities targeting pure Go programs, despite the popularity of the language.
You said that because you assumed Go is memory-safe in all conditions.
> Go is memory-safe
Yes, but only if there's no data race.
Go is not like Java. Java doesn't guarantee no data race, but when it happens, it's still memory-safe.
I fail to see how a racy Java program is more memory safe than a racy Go program?
Go slices are fat pointers to undecorated memory. The slice itself is a 3-tuple of pointer, length, and capacity. If you append to a slice that's already at capacity, the Go runtime will allocate new memory for you and return a new 3-tuple. If you assign that result to a variable that's also being accessed by another goroutine, the latter can observe the slice in an inconsistent state. It can, for example, see the old pointer but with the new length, allowing out-of-bounds access. None of this requires unsafe code.
The same issue applies to string and interface variables, which are also fat pointers.
Shared Go slices are a bad mix in concurrent code. This is a given. But its also not a fair comparison, you should instead compare java arrays to go arrays, not slices.
This goes for slices, strings and maps. Those a usually wrapped in a mutex, or used with sync primitives like sync.Map.
The point is that Java does not have this problem in the language or the standard library. Of course, you should not write racy Go code; the language provides ample ways to avoid the race, such as channels; and the race detector will generally find such racy code, provided you turn it on. However, the issue is that this race leads to memory-safety violations; it can occur especially in code written by novice Go programmers, and it's well acknowledged by the language authors [1].
The same can be said of C or C++ constructs (and many "anti-Rust" people have historically said that) -- the point is that their use is not enforced by the language and so bugs can lead to panics.
I write a fair amount of Go and Rust so I really don't think either language's flaws are fatal, but it comes off as weirdly defensive to redefine memory and data safety to be "well if you use it properly it's safe". It's totally fine to say this is a problem the Go language did not find important enough to require compile time enforcement and so solving it is done by convention and testing with the race detector (which a similar answer C and C++ give to this problem).
The definition I'm giving is the same as the ISRG's definition at MemorySafety.org. It's the thing everybody is talking about when they talk about memory safety.
The claim being made here is "big if true", because it would imply a lot more languages than Go "aren't memory safe", despite decades without memory corruption exploits.
It's remarkably easy to segfault Go applications with data races. Any object with multiple words (so a slice that's an array pointer, a size, and a capacity. Or a fat pointer with the object pointer and the vtable pointer), can be read in an inconsistent state from two threads which can cause out of bounds reads and writes. And this comes up all the time with how heavily the language encourages concurrency.
It's just difficult to actually exploit because of other considerations that practically add a lot of runtime entropy.
The was for a time a vogue for "zero trust networking" and I'm fond of pointing out that the same thing happened there: people would come up with their own axiomatic derivation of what "zero trust" meant, but in reality it was a term of art meaning "non-Google implementations of BeyondCorp".
Terms of art are kryptonite for message board nerds.
And yeah, we tend to use the PLT definitions when we're talking about literal semantics of programming languages. Nothing in this thread mandates a security focused sub-definition.
And even Rob Pike described Go as "not purely memory safe", in a slide that obviously references this exact data race behavior. https://go.dev/talks/2012/splash.slide#49 They considered this a practical tradeoff for simplicity versus the major managed languages defining what happens during data races in a way that doesn't allow you to break memory safety.
Iny experience, the ultra security focused view isn't what most people think of when they hear memory safety. It's one aspect, but one among many. For instance debugability is much nicer when you can't break the object model and get a nice trace out of the system versus when you're trying to find memory corruption with gdb or something.
That said, even the ISRG definitions I've found don't list protection from exploits. It does include out of bounds memory accesses in what makes a memory unsafe language, which would discount Go. Yes, they explicitly list Go as a memory safe language, but there's a good chance that they simply don't know about this behavior.
As someone who used to freelance in exploit research, the go behavior doesn't seem insurmountable for finding an exploit on its own. Frankly it's all the other ecosystem stuff that makes it harder. The fact that go code has a habit of being deployed multiple times a day, you a lot of times don't have access to the binaries, there's generally no dynamic (on Linux) so you have no relatively stable code to find gadgets in, etc. (Although there are aspects of the language like the relative simplicity of the compiler that do help you in some of those regards).
Seeing a correctness issue that makes Go not memory safe in some circumstances warrants questioning whether it is memory safe. On balance, you might say it is, but to constantly tell people they are wrong for saying otherwise is policing a shared term.
To get rid of this issue, go must add a level of indirection or track aliasing at compile time; the tradeoff Go made here is perfectly reasonable.
See for example comments from tptacek like:
https://news.ycombinator.com/item?id=43335748
https://news.ycombinator.com/item?id=46028232
https://news.ycombinator.com/item?id=44672371
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
At some point in the future, a fully backwards compatible Rust compiler will report an error when you try to compile cve-rs.
There are no known instances of this bug being encountered in the wild, and if you look into it, you will see how extremely unlikely such code is.
I like Rust, but with this bug existing for so long, I personally no longer think of it as memory-safe.
I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.
Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].
[0]: https://news.ycombinator.com/item?id=40431444
[1]: https://blog.rust-lang.org/2026/08/21/enabling-next-solver-o...
btw, it's not actually that hard to write correct code in C++, easier than in C because you have all the container types. The problem is that nothing will tell you when you write incorrect code - there's no guarantee.
The cve-rs repo is not meant to be the toxic gotcha aimed at Rust language maintainers you seem to think it is. It’s a repro case.
I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.
(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)
My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.
That throws a NullReferenceException
When we finally rid ourselves of C and C++ is so larded over with extensions and additions and features that we can finally plausibly say the C subset is just not in use anymore, we can perhaps consider as a community expanding what "memory safe" means, but in the meantime it has some very important meanings and we should not try to augment the term. Memory safety doesn't mean anything like "forcing exhaustiveness into sum type deconstructions" or "never has a race condition" (though it does mean said race condition shouldn't be something that allows you to escape out of an array or forcibly change the type on something in a way the language doesn't normally permit) or any of several other things that may be very nice to have indeed, but are not part of the definition of "memory safe".
Memory safe is a very old concept, and almost everything is memory safe now. But not quite, and as such the term still has use. And also zig for some reason gave it up so it won't be disappearing as soon as I'd like.'
As an (outside go) example, Ocaml (5) promises strong memory safety, but not to be data race free. A data race is not something we can prevent, because its usually not bound by code, but by time and the race-source rarely in source-code.
This means we have data races in http, database inserts etc. The source is usually not a concurrent task in source code-land.
My point is "races" happen all over. In concurrent code, databases, http and pretty much anywhere where you have some kind of timing, not scoped to a unit.
I think this should make the distinction between data races and race conditions pretty clear.
Not sure why you would be that nitpicky for something so trivial?
In the end its the same problem, dressed up differently.
https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...
https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)
I do think the nitpicking about this is mostly from people that want to say “my favorite language is safer than Go” which stupid and annoying.
As I understand it, part of the reason it took a while is that the core Go team was generally of the opinion that doing user-facing SIMD APIs the right way was to design a high-level, cross-platform API that would stand the test of time, and that was then punted a few times given its complexity and need to do other things.
Part of what helped the current approach take off was switching to a philosophy of designing a lower-level architecture-dependent API first (the 'simd/archsimd' package), and then later doing a higher-level portable API (the 'simd' package, which is topic of this blog post).
That two-level approach I think also gave some additional freedom for the design and implementation of the friendlier / high-level 'simd' package, including because the lower-level 'simd/archsimd' package is available for people who need or want to drop down.
It's a nice design.
There are pros and cons of course. You don't have 17 different ways to iterate over an array, so that's nice. But you also went 13 years without generics, despite them being one of the most requested features, because the designers didn't want that complexity inside Go.
Overall I think Go is better for this philosophy but there are times where the language is clearly written more for its maintainers than it's users.
Go shipped with generics (aka bounded parametric polymorphism), but only for built-in types: slices, arrays, and maps. That, with subtyping via interfaces, handled most demand for generics. The most common pain point was custom containers.
Go was first released in November 2009. Russ Cox posted "The Generic Dilemma" [1] in December 2009. The comments show the generics debate raging from the earliest days.
As a fun side note, I forgot I posted a comment on that post pointing to Ada's generics. I was in college, and Ada was our intro language.
[1]: https://research.swtch.com/generic
> the designers didn't want that complexity inside Go.
Yes, with some nuance. Go's goal of writing server programs didn't require the type-system complexity and run-time hit of user-defined generics. [2]
> Go was intended as a language for writing server programs [...] Polymorphic programming did not seem essential [...] so was initially left out for simplicity. > > Generics are convenient but they come at a cost in complexity in the type system and run-time. It took a while to develop a design that we believe gives value proportionate to the complexity.
[2]: https://go.dev/doc/faq#beginning_generics
Out of curiosity, I collected all proposals for Go's journey to generics. https://gist.github.com/jschaf/eaa7aff1af14ea7276a18a1b7370d...
Personally I will implement it in https://github.com/viggy28/streambed
This naturally is an easier way.
The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.
While reaching out to CGO is the easier way, it doesn't mean it is the only tool available in Go.
There's a CL stack here:
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.)
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.
> 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:
SVE and RVV, because they are "scalable", may end up with a larger amount of replication.
Go uses fixed-size stack frames, so spill space is fixed size, etc. We could "just" fix this limitation, or we could generate multiple sizes for what actually exists in the wild, with a masked implementation for longer. So, SVE would end up with 0 (emulation), 128, 256, and 512-masked, plus (as arm64) would also have NEON and NEON-noclmul (Raspberry Pi). I'm not sure what sizes exist for RVV.
The intersection would be the operations supported by all platforms and so would not have gaps.
> 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/
- WebAssembly: 4 float32s
- Mojo: N float32s where N is a compile-time parameter
- Go simd: vector of float32s
Two of the "conversion" methods between int and uint vectors compiled to movd or less (but the convert from int to float32 vector does not) and are actually identical to corresponding zero-cost reshapes.
Conversion between int vectors and masks may be zero-cost; it depends on the platform (zero cost on Wasm, NEON, AVX, AVX2; change in representation on AVX512 and SVE).
There's also pattern-based optimization going on in the backend of the compiler, so if (on AVX512 or SVE) you do some operation followed by an IfElse, odds are pretty good the two "methods" will compile down to a single instruction. We did this API factoring so that we could support (many) fewer methods, and it also increases the similarity between different platforms.
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
You'd think these people would know the meaning of API, no?
> The interface to a software library is one type of API. The API describes and prescribes the "expected behavior" (a specification) while the library is an "actual implementation" of this set of rules.
Yes, I still wonder why you'd be picking this particular silly semantic battle.
> The term API is often used to refer to web APIs, which allow communication between computers that are joined by the internet. There are also APIs for programming languages, software libraries, computer operating systems, and computer hardware.
Uncorroborated by WP, note.
> If you disagree perhaps you should share your preferred term here?
Library functions.