How generics are implemented in Go 1.18

Re:How generics are implemented in Go 1.18 by yakubin on Tuesday March 01, 2022 @04:26PM (#30520232)

Rust does compile slower than Go, but it's not due to generics. It's mostly due to LLVM codegen and procedural macros. Go has the benefit of not relying on LLVM and not having procedural macros.

[ Parent | on HN ]

Re:How generics are implemented in Go 1.18 by edflsafoiewq on Tuesday March 01, 2022 @06:41PM (#30521600)

A lot of the IR comes from expanding huge stacks of generic functions. I don't think the issue can't be neatly partitioned up like that.

[ Parent | on HN ]

Re:How generics are implemented in Go 1.18 by codeflo on Tuesday March 01, 2022 @04:48PM (#30520488)

Absolutely true. I’d add that Rust is also doing a lot more expensive optimizations in release builds.

[ Parent | on HN ]

Re:How generics are implemented in Go 1.18 by jcelerier on Tuesday March 01, 2022 @04:56PM (#30520599)

Until recently Go didn't even use registers for passing arguments, it just put everything on the stack like in a 1965 textbook (https://go.googlesource.com/proposal/+/refs/changes/78/24817...)

[ Parent | on HN ]

Re:How generics are implemented in Go 1.18 by eloff on Tuesday March 01, 2022 @05:04PM (#30520672)

If you mean for function calls, I believe you're correct, not taking into account inline functions.

However, for code generation Go obviously uses registers since way before the 1.0 days.

[ Parent | on HN ]

Re:How generics are implemented in Go 1.18 by geodel on Tuesday March 01, 2022 @08:04PM (#30522324)

You are right of course about LLVM being source of slowness.

In general discussion I see around is that all Rust's perf optimizations are to Rust's credit (nothing about LLVM optimization) while all woes around Rust's compile time lay at step of LLVM and Rust is not be blamed.

[ Parent | on HN ]