I will add though, I agree with "messy bag of types." 😂 I'm just not sure how they would avoid it without giving something up.
January 11, 2026 at 2:43 AM
I will add though, I agree with "messy bag of types." 😂 I'm just not sure how they would avoid it without giving something up.
Perhaps I'm missing something?
January 11, 2026 at 2:14 AM
Perhaps I'm missing something?
Hm, I'm not sure that works. Then, the vector types have to be actually different types.
That is, amd64.Uint64x2 would be different from arm64.Uint64x2, which hurts portability. And you can't just alias the two types because their method sets are different.
That is, amd64.Uint64x2 would be different from arm64.Uint64x2, which hurts portability. And you can't just alias the two types because their method sets are different.
January 11, 2026 at 2:14 AM
Hm, I'm not sure that works. Then, the vector types have to be actually different types.
That is, amd64.Uint64x2 would be different from arm64.Uint64x2, which hurts portability. And you can't just alias the two types because their method sets are different.
That is, amd64.Uint64x2 would be different from arm64.Uint64x2, which hurts portability. And you can't just alias the two types because their method sets are different.
Don't mean to speak for the authors just sharing from what's already been stated. The public proposal is pretty up-front about this. It's in the design goals (and immediately following) section.
github.com/golang/go/is...
github.com/golang/go/is...
simd/archsimd: architecture-specific SIMD intrinsics under a GOEXPERIMENT · Issue #73787 · golang/go
Update (12/16/2025): The AMD64 low-level SIMD package is now available in Go 1.26 RC1 under GOEXPERIMENT=simd. Also, the package is renamed to simd/archsimd, per #76473,. See #73787 (comment) . Upd...
github.com
January 10, 2026 at 8:08 PM
Don't mean to speak for the authors just sharing from what's already been stated. The public proposal is pretty up-front about this. It's in the design goals (and immediately following) section.
github.com/golang/go/is...
github.com/golang/go/is...
The goal is that the types are shared across platforms, but supported methods on those types are best-effort (no emulation, but for example 'Add' will be called 'Add' everywhere).
This means *some* amount of portability, even at the lowest level. Separate packages would give up these benefits.
This means *some* amount of portability, even at the lowest level. Separate packages would give up these benefits.
January 10, 2026 at 8:08 PM
The goal is that the types are shared across platforms, but supported methods on those types are best-effort (no emulation, but for example 'Add' will be called 'Add' everywhere).
This means *some* amount of portability, even at the lowest level. Separate packages would give up these benefits.
This means *some* amount of portability, even at the lowest level. Separate packages would give up these benefits.
Indeed... 😂 github.com/golang/go/is...
December 9, 2025 at 1:35 AM
Indeed... 😂 github.com/golang/go/is...
I've been toying with ideas on how to make the generic version public without waiting on a v2. Hopefully I'll be able to get something out in the near future. 😅 This certainly adds new motivation!
November 30, 2025 at 5:07 PM
I've been toying with ideas on how to make the generic version public without waiting on a v2. Hopefully I'll be able to get something out in the near future. 😅 This certainly adds new motivation!
This is mostly the same content as the blog post (go.dev/blog/greente...), just in video form.
November 20, 2025 at 12:33 AM
This is mostly the same content as the blog post (go.dev/blog/greente...), just in video form.
Reposted by Michael Knyszek
For some added fun, also see go.dev/cl/715362, wherein I discover that VPCOMPRESSQ is horrifically slow on AMD Zen 4, but only with a memory destination.
And thanks to @lemire.bsky.social for writing about this, which made this much faster to track down!
And thanks to @lemire.bsky.social for writing about this, which made this much faster to track down!
Gerrit Code Review
go.dev
October 29, 2025 at 7:20 PM
For some added fun, also see go.dev/cl/715362, wherein I discover that VPCOMPRESSQ is horrifically slow on AMD Zen 4, but only with a memory destination.
And thanks to @lemire.bsky.social for writing about this, which made this much faster to track down!
And thanks to @lemire.bsky.social for writing about this, which made this much faster to track down!
I can certainly see how that would be frustrating. I referenced the closed-as-dupe issues in the new issue as well, thanks for pointing them out!
October 18, 2025 at 5:31 PM
I can certainly see how that would be frustrating. I referenced the closed-as-dupe issues in the new issue as well, thanks for pointing them out!
October 18, 2025 at 5:27 PM
Not to speak for the person who closed it, but it's probably still accurate that nobody plans to work on it in the near future. However, opening a proper the feature request or proposal and leaving it open seems reasonable.
October 18, 2025 at 5:17 PM
Not to speak for the person who closed it, but it's probably still accurate that nobody plans to work on it in the near future. However, opening a proper the feature request or proposal and leaving it open seems reasonable.
There might just be a misunderstanding here. That issue was about naming a flag that didn't end up making it in. In that context, it makes sense to close the issue, I think.
October 18, 2025 at 5:17 PM
There might just be a misunderstanding here. That issue was about naming a flag that didn't end up making it in. In that context, it makes sense to close the issue, I think.
Reposted by Michael Knyszek
I'd love to hear from folks about your experiences. Do you use execution tracing often. If not, is it due to lack of need, lack of documentation, missing information, tooling issues, etc?
September 26, 2025 at 7:32 PM
I'd love to hear from folks about your experiences. Do you use execution tracing often. If not, is it due to lack of need, lack of documentation, missing information, tooling issues, etc?