Generics can make your Go code slower • Hacker News Board

Re: Generics can make your Go code slower

#21

Post by tanoku » Wed, Mar 30, 2022, 4:56 PM UTC

throwoutway wrote: post #16

The first code-to-assembly highlighting example here is beautiful. Question to the authors— is that custom just for this article? Is there an open source CSS library or something that does this?

Hey, author here. Thanks for the kind words! This is a custom pipeline that I designed for the article. It's implemented as a Node.js library using SVG.js and it statically generates the interactive SVGs directly in the static site generator I was using (Eleventy) by calling out to the Go compiler and extracting assembly for any lines you mark as interesting. It turned out very handy for iterating, but it's not particularly reusable I'm afraid!

Re: Generics can make your Go code slower

#22

Post by tsimionescu » Wed, Mar 30, 2022, 4:57 PM UTC

mrweasel wrote: post #17

ramesh31 wrote: post #15

Well sure. Not writing hand tuned assembly can make your code slower, too. Go's value as a language is how it fills the niche between Rust and Python, giving you low level things like manual memory control, while still making tradeoffs for performance and developer experience.

I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.

It depends what they are replacing. Typically, generics used to replace runtime polymorphism (using [T any] []T instead of []any) would be a speed boost in C#, C++, or Rust; and would have no impact on speed in Java.

Re: Generics can make your Go code slower

#23

Post by whimsicalism » Wed, Mar 30, 2022, 4:58 PM UTC

mrweasel wrote: post #17

ramesh31 wrote: post #15

Well sure. Not writing hand tuned assembly can make your code slower, too. Go's value as a language is how it fills the niche between Rust and Python, giving you low level things like manual memory control, while still making tradeoffs for performance and developer experience.

I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.

> I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.

? In most languages, it is compile-time overhead, not runtime.

Re: Generics can make your Go code slower

#24

Post by zellyn » Wed, Mar 30, 2022, 4:58 PM UTC

(off-topic) Anyone else using Firefox know why the text starts out light gray and then flashes to unreadably dark gray after the page loads? (The header logo and text change from gray to blue too)

Re: Generics can make your Go code slower

#25

Post by whimsicalism » Wed, Mar 30, 2022, 5:00 PM UTC

jatone wrote: post #18

what I expect to happen now that golang has generics and reports like these will show up is golang will explore monomorphizing generics and get hard numbers. they may also choose to use some of the compilation speeds they've gained from linker optimizations and spend that on generics. I can't imagine monomorphizing being that big of a deal during compilation if the generation is defered and results are cached.

I am unfamiliar with Go. This article discusses that they have decided to go for runtime lookup. Is there any reason why that implementation might make monomorphizing more difficult?

Re: Generics can make your Go code slower

#26

Post by msla » Wed, Mar 30, 2022, 5:03 PM UTC

tanoku wrote: post #21

throwoutway wrote: post #16

The first code-to-assembly highlighting example here is beautiful. Question to the authors— is that custom just for this article? Is there an open source CSS library or something that does this?

Hey, author here. Thanks for the kind words! This is a custom pipeline that I designed for the article. It's implemented as a Node.js library using SVG.js and it statically generates the interactive SVGs directly in the static site generator I was using (Eleventy) by calling out to the Go compiler and extracting assembly for any lines you mark as interesting. It turned out very handy for iterating, but it's not parti…

I agree with the commenter you're replying to; I'd only add that Intel syntax is much more readable than AT&T.

Re: Generics can make your Go code slower

#27

Post by wtetzner » Wed, Mar 30, 2022, 5:04 PM UTC

zellyn wrote: post #24

(off-topic) Anyone else using Firefox know why the text starts out light gray and then flashes to unreadably dark gray after the page loads? (The header logo and text change from gray to blue too)

I'm using Firefox and don't see that issue. Maybe some kind of plugin you have installed?

Re: Generics can make your Go code slower

#28

Post by mrweasel » Wed, Mar 30, 2022, 5:05 PM UTC

zellyn wrote: post #20

mrweasel wrote: post #17

Earlier quoted context omitted.

I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.

I don't know about you, but when I imagine what compilers do with generic code, I typically imagine monomorphization, which (aside from increasing cache pressure a little), should generally not make things slower, but rather introduce possibilities for inlining that could make it faster.

Apparently I scrolled right past that bit of the article. I’m a little unsure how it’s suppose to make the code faster, but maybe because I compare it wrong. The alternative to generics is writing all the different function by hand, in my mind at least. I don’t fully understand how generics are suppose to be made faster than a custom function for that datatype.

Re: Generics can make your Go code slower

#29

Post by pphysch » Wed, Mar 30, 2022, 5:05 PM UTC

My first use of Go generics has been for a concurrent "ECS" game engine. In this case, the gains are pretty obvious. I think.

I get to write one set of generic methods and data structures that operate over arbitrary "Component" structs, and I can allocate all my components of a particular type contiguously on the heap, then iterate over them with arbitrary, type-safe functions.

I can't fathom that doing this via a Component interface would be even as close as fast, because it would destroy cache performance by introducing a bunch of Interface tuples and pointer dereferencing for every single instance. Not to mention the type-unsafe code being yucky. Am I wrong?

FWIW I was able to update 2,000,000 components per (1/60s) frame per thread in a simple Game of Life prototype, which I am quite happy with. But I never bothered to evaluate if Interfaces would be as fast

Re: Generics can make your Go code slower

#30

Post by jatone » Wed, Mar 30, 2022, 5:05 PM UTC

eatonphil wrote: post #10

Key tldr from me: > Ah well. Overall, this may have been a bit of a disappointment to those who expected to use Generics as a powerful option to optimize Go code, as it is done in other systems languages. We have learned (I hope!) a lot of interesting details about the way the Go compiler deals with Generics. Unfortunately, we have also learned that the implementation shipped in 1.18, more often than not, makes Gener…

I agree. I find this snippet interestingly incorrect.

> with very few regressions, up until now.

the idea that this is a regression is silly. you can't have a regression unless old code is slower as a result. which is clearly not the case. its just a less than ideal outcome for generics. which will likely get resolved.