Generics can make your Go code slower • Hacker News Board

Re: Generics can make your Go code slower

#11

Post by morelisp » Wed, Mar 30, 2022, 4:34 PM UTC

linkdd wrote: post #9

kubb wrote: post #3

Reading the title I'm worried, should I keep using reflection instead?

Premature optimization is a bad thing. Just implement naively, then if you have performance issues identify the bottleneck.

Ignorance of how your language works is a bad thing.

Knowing where performance issues with certain techniques might arise is not premature optimization. Implement with an appropriate level of care, including performance concerns. Not every kind of poor performance appears as a clear spike in a call graph, and even fewer can be fixed without changing any external API.

Re: Generics can make your Go code slower

#12

Post by jerf » Wed, Mar 30, 2022, 4:35 PM UTC

kubb wrote: post #3

Reading the title I'm worried, should I keep using reflection instead?

If the information in this article is make-or-break for your program, you probably shouldn't have chosen Go.

In the grand space of all programming languages, Go is fast. In the space of compiled programming languages, it's on the slower end. If you're in a "counting CPU ops" situation it's not a good choice.

There is an intermediate space in which one is optimizing a particular tight loop, certainly, I've been there, and this can be nice to know. But if it's beyond "nice to know", you have a problem.

I don't know what you're doing with reflection but the odds are that it's wildly slower than anything in that article though, because of how it works. Reflection is basically like a dynamically-typed programming language runtime you can use as a library in Go, and does the same thing dynamically-typed languages (modulo JIT) do on their insides, which is essentially deal with everything through an extra layer of indirection. Not just a function call here or there... everything. Reading a field. Writing a field. Calling a function, etc. Everywhere you have runtime dynamic behavior, the need to check for a lot of things to be true, and everything operating through extra layers of pointers and table structs. Where the article is complaining about an extra CPU instruction here and an extra pointer indirection there, you've signed up for extra function calls and pointer indirections by the dozens. If you can convert reflection to generics it will almost certainly be a big win.

(But if you cared about performance you were probably also better off with an interface that didn't fully express what you meant and some extra type switches.)

Re: Generics can make your Go code slower

#13

Post by AYBABTME » Wed, Mar 30, 2022, 4:42 PM UTC

kubb wrote: post #3

Reading the title I'm worried, should I keep using reflection instead?

Use generics if it makes your dev experience better. Profile if it's slow. Optimize the slow bits.

Re: Generics can make your Go code slower

#14

Post by shadowgovt » Wed, Mar 30, 2022, 4:44 PM UTC

jerf wrote: post #12

kubb wrote: post #3

Reading the title I'm worried, should I keep using reflection instead?

If the information in this article is make-or-break for your program, you probably shouldn't have chosen Go. In the grand space of all programming languages, Go is fast. In the space of compiled programming languages, it's on the slower end. If you're in a "counting CPU ops" situation it's not a good choice. There is an intermediate space in which one is optimizing a particular tight loop, certainly, I've been there,…

This is good high-level advice as well as low-level advice.

Go is positioned to be most useful as an alternative to Java, and to C++ where performance isn't the key factor (i.e. projects where C++ would be chosen because "Enh, it's a big desktop application and C++ is familiar to a lot of developers," not because the project actually calls for being able to break out into assembly language easily or where fine-tuning performance is more important than tool-provided platform portability).

Re: Generics can make your Go code slower

#15

Post by ramesh31 » Wed, Mar 30, 2022, 4:45 PM UTC

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.

Re: Generics can make your Go code slower

#16

Post by throwoutway » Wed, Mar 30, 2022, 4:49 PM UTC

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?

Re: Generics can make your Go code slower

#17

Post by mrweasel » Wed, Mar 30, 2022, 4:52 PM UTC

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.

Re: Generics can make your Go code slower

#18

Post by jatone » Wed, Mar 30, 2022, 4:54 PM UTC

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.

Re: Generics can make your Go code slower

#19

Post by lalaithion » Wed, Mar 30, 2022, 4:55 PM UTC

kubb wrote: post #3

Reading the title I'm worried, should I keep using reflection instead?

Very few people are actually answering your question, so I'll answer it: Generics are slower than concrete types, and are slower than simple interfaces. However, the article does not bother to compare generics with reflection, and my intuition says that generics will be faster than reflection.

Re: Generics can make your Go code slower

#20

Post by zellyn » Wed, Mar 30, 2022, 4:56 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 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.