Julia does that too.

Yes: https://www.mathworks.com/help/fixedpoint/ref/half.fma.html

I'm grateful that Go a non-proprietary language offers these features.

Yeah, that is what I have heard from some NVidia folks as well, like Bryce Adelstein, use the libraries as much as possible, and leave the kernels for experts.

However even then, it depends on how the libraries API surface looks like.

With AI, I expect it to eventually be good enough for us to finally have 5 GLs, so it won't really matter.

"CGO 2022 Keynote: Compiler 2.0"

https://www.youtube.com/watch?v=w_sX9aZoZxg

In 2026 if you are not doing A with AI you are doing it wrong /s

You probably weren't looking for a tutorial about SIMD, but just in case you were interested, Mitchell [0] did one recently that got on HN [1]

[0] Mitchell Hashimoto: "Everyone Should Know SIMD" https://mitchellh.com/writing/everyone-should-know-simd

[1] https://news.ycombinator.com/item?id=49010648

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.

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.

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.)

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

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,....

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.

Memory safety != Data race free

I have not written a line of Java in 15 years. But im pretty sure Java has threads? Once you have threads, you pretty much have data races.

        Thread a = new Thread(() -> x++);
        Thread b = new Thread(() -> x++);

        a.start();
        b.start();

Memory safety isn’t really about vulnerabilities. This thread is about Go, so I won’t go further into it here.

I suppose that if you create a map in one thread, and then access it from another thread, then that might cause segmentation faults? Because map is a type that is implemented in C.

Neither Java or Go guarantees data-race freedom. A data race does not by itself make ordinary Java or Go code memory-unsafe in the C/C++ sense.

I fail to see how a racy Java program is more memory safe than a racy Go program?

Yes, but in practice they are extremely hard to exploit. It has been discussed extensively here on HN and in other forums.

That's not what "memory safe" means. "Memory safe" is a term of art meaning "not susceptible to memory corruption exploits", like stack and heap overflows, UAFs, and type confusion. Last I checked, there are essentially no non-contrived memory corruption exploits for Go programs; the best you get are people demonstrating register control on contrived programs.

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.

Yeah, we get it, you performatively hate go.

No, Rust does not allow that. The current Rust compiler does, but that’s a bug that is being fixed.

At some point in the future, a fully backwards compatible Rust compiler will report an error when you try to compile cve-rs.

He’s very wrong about this. Just because ‘tptacek posts a lot and did security once upon a time does not make him “broad consideration”.

And then use Go's pseudo exception handling and recover.

This is not generally considered part of the "memory safety" contract. You can not lift a nil pointer exception into a replacement for Go's "unsafe" library.

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.'

Now you are pushing pixels. A data-race IS a kind of race condition.

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.

Mostly safe, contrary to other safer languages, Go memory model doesn't prevent data tearing.

People were definitely asking for it.

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:

One wonders why you wonder.

https://en.wikipedia.org/wiki/API

They could have used third party packages or Assembly directly.

This naturally is an easier way.

Seconded!! This doesn’t really help the well established codebases much that are already doing this on a platform specific path but in general this is much appreciated for the future.

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.

I hope portable simd will be stabilized some time in rust :/

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.