iiinova — where your digital self keeps evolving

Michael Knyszek @michael.express · 02/09/2026

also, pointers get passed the same way as integers. there's nothing special about pointers in the calling convention.

000

Michael Knyszek @michael.express · 02/09/2026

that being said, my point really depends on readFloat being inlined.

100

Michael Knyszek @michael.express · 02/09/2026

they are. but there might be differences in how the compiler treats a struct vs. separate values. suppose you only use a subset of values and readFloat is inlineable. I think the compiler won't destructure a struct with this many fields, so it might fail to eliminate some dead computation.

200

Michael Knyszek @michael.express · 11/01/2026

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.

110

Michael Knyszek @michael.express · 11/01/2026

Perhaps I'm missing something?

100

Michael Knyszek @michael.express · 11/01/2026

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.

100

Michael Knyszek @michael.express · 10/01/2026

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.

120

Michael Knyszek @michael.express · 09/12/2025

Indeed... 😂 github.com/golang/go/is...

030

Michael Knyszek @michael.express · 30/11/2025

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!

160

Michael Knyszek @michael.express · 20/11/2025

This is mostly the same content as the blog post (go.dev/blog/greente...), just in video form.

020

Reposted by Michael Knyszek

Go @golang.org · 14/11/2025

“Go’s Sweet 16” by Austin Clements, for the Go team — go.dev/blog/16years #golang

14219

Reposted by Michael Knyszek

Russ Cox @swtch.com · 30/10/2025

Happy to see someone outside Google rebuild/verify Go toolchains. Thanks @agwa.name! www.agwa.name/blog/post/ve... "So far, Source Spotter has successfully reproduced every toolchain since Go 1.21.0, for every architecture and operating system. As of publication time, that's 2,672 toolchains!"

agwa.name

I'm Independently Verifying Go's Reproducible Builds

Introducing Source Spotter, a Go Checksum Database auditor and Go toolchain reproducer

0787

Reposted by Michael Knyszek

Michael Pratt @prattmic.com · 29/10/2025

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!

go.dev

Gerrit Code Review

082

Reposted by Michael Knyszek

Go @golang.org · 29/10/2025

“The Green Tea Garbage Collector” by Michael Knyszek and Austin Clements — go.dev/blog/greenteagc #golang

15417

Michael Knyszek @michael.express · 18/10/2025

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!

020

Michael Knyszek @michael.express · 18/10/2025

Filed github.com/golang/go/issues/75967.

010

Michael Knyszek @michael.express · 18/10/2025

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.

210

Michael Knyszek @michael.express · 18/10/2025

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.

100

Reposted by Michael Knyszek

Michael Pratt @prattmic.com · 26/09/2025

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?

251

Reposted by Michael Knyszek

Michael Pratt @prattmic.com · 26/09/2025

Go's execution tracer is a woefully underutilized tool. It contains tons of information about what is happening at any given moment that you won't get with a profile. In addition to showing flight recording capabilities, this post provides a nice example of how to use tracing to diagnose a problem.

1309

Reposted by Michael Knyszek

Go @golang.org · 26/09/2025

“Flight Recorder in Go 1.25” by Carlos Amedee and Michael Knyszek — go.dev/blog/flight-recorder #golang

04311

Reposted by Michael Knyszek

Florian Zenker 🏳️‍⚧️🏳️‍🌈 @flo.znkr.io · 01/09/2025

The GopherCon EU videos are online. I really enjoyed @misago.org’s about testing/synctest. But there were so many good talks, maybe watch them all? youtu.be/oIC3zhTAOsY #gopherconeu #golang

youtu.be

Testing Time (and other asynchronous code) - Damien Neil | GopherCon EU 2025

YouTube video by GopherCon Europe

0125

Reposted by Michael Knyszek

Michael Pratt @prattmic.com · 01/09/2025

My GopherCon EU talk about Swiss Table maps is now available! youtu.be/aqtIM5AK9t4

youtu.be

Faster Go Maps With Swiss Tables - Michael Pratt | GopherCon EU 2025

YouTube video by GopherCon Europe

0259

Reposted by Michael Knyszek

GopherCon @gophercon.com · 27/05/2025

What if Go’s garbage collector could just run faster? Join @michael.express from the Go Team for a deep dive into Green Tea — a new experimental parallel mark algorithm designed to speed up Go’s garbage collector through better cache locality and SIMD. www.gophercon.com/agenda/sessi...

093

Michael Knyszek @michael.express · 04/01/2025

is that a pen plotter drawing by Michael Fogleman, maybe? (www.michaelfogleman.com/plotter/)

110

Michael Knyszek @michael.express · 25/12/2024

Agreed. It's already a niche tool and having it actually cause a real problem is likely even rarer than that. It could be useful to us working on std, I guess?

000

Michael Knyszek @michael.express · 25/12/2024

The sketch doesn't currently report issues related to the tiny allocator, but yeah, I'm thinking that such a GODEBUG could.

000

Michael Knyszek @michael.express · 24/12/2024

If such a debugging mode would be useful, what would be the most helpful information for debugging? Stack trace where the finalizer was applied? The object's type?

000

Michael Knyszek @michael.express · 24/12/2024

How often do people run into the SetFinalizer footguns in Go? (Accidental cycle, for example.) Would a GODEBUG that does something slow but tells you when you've made a mistake be useful to you? (Maybe even just for tests, to prevent a regression?) Sketch: go-review.googlesource.com/c/go/+/634599

go-review.googlesource.com

Gerrit Code Review

464