4 ms·

> At most you’re getting the benefits of unboxing Which is.. 3x? or 10x? > These tests are probably just picking up the cost of an extra allocation required t

> At most you’re getting the benefits of unboxing Which is.. 3x? or 10x? > These tests are probably just picking up the cost of an extra allocation required to box a primitive type as an interface. I've seen unboxing deliver 100x speed ups cause it allowed the compiler to auto-vectorize multiple loops, fuse them, optimize stuff better etc. Stuff that it can't do if it doesn't know the memory layout of things, or if there are "optimization barriers" inserted in between all these steps (`interface {}`). --- TBH it's 2022 and it seems that "Go" devs are just seeing fire for the first time in their lives. Yeah, fire heats. And yeah, this type of stuff if why people don't put Go in the same bag of languages as C++ or Rust. Go feels fast if you are coming from Python, but if you actually look at what the hardware can deliver in terms of FLOPs and BW, Go programs run at 0% of hardware peak (and no, just because your task manager shows go threads using 100% of the CPU doesn't mean that it is achieving 100% of peak CPU perf).

jpgvm 5y ago
Exactly. Go was (still is tbh) slow. that is why these improvements are possible. Fast is relative ofc but if you are going to introduce the words "low level" in your description then don't be surprised when C/C++/Rust rear their ugly (but very fast) heads.
- preseinger 5y ago
  > Go was (still is tbh) slow. "Slow" isn't an objective metric. Slow how?
  - jpgvm 5y ago
    It's less that it isn't objective but more that it's relative. As I mentioned in my original comment once you start throwing around the expression "low-level language" or "systems language" you invite comparisons to C/C++/Rust. Thus you will end up with a list of points like this: It makes less efficient use of hardware due to poor vectorization and lack of JIT to take advantage of this information which would be apparent at runtime. Namely escape analysis would be particularly good. I imagine that Go on Graal would be a very very fast language if time was invested there. Also until recently generics weren't a thing so it made it impossible to do -high performance- generic data-structures without code-gen. They were possible, but slow as balls due to interface{} and reflection. It's garbage collector is mediocre for latency, nothing impressive. But it's straight dog shit for throughput. Definitely not -fast- compared to JVM/Hotspot/ZGC. So, on the good side of Go it provides easy/good access to primitive types and primitive arrays of said types so as long as you know what you are doing you can generally massage the compiler into doing something not completely stupid. That said if I want to write really fast code in something that isn't C/C++/Rust I would much prefer Java or C#... or more logically if FAST is the primary concern then I would probably pick C++ or Rust.
    - preseinger 5y ago
      > It's garbage collector is mediocre for latency, nothing impressive. Go's GC is best-in-class for latency. What makes you think otherwise?
      - jpgvm 5y ago
        It's on par with other latency optimized GCs for pure pause time but because it's architecture pays a gigantic throughput cost making it only a mediocre GC overall. ZGC puts out the same pause numbers with monstrous throughput in comparison.
foldr 5y ago
Even in these microbenchmarks it’s not 10x. Boxing can be faster or slower depending on the context. For example, if the objects you are storing are large, unboxing them (rather than storing pointers to them) could well make the queue perform worse, as extending the arrays will require more memory to be copied. There’s no doubt that the unboxing permitted by (Go’s) generics will sometimes lead to better performance. But I think that the article is exaggerating. > TBH it's 2022 and it seems that "Go" devs are just seeing fire for the first time in their lives. Come on, let’s keep this patronizing and flamey kind of commentary off HN. I for one am a language nerd who’s tried plenty of languages with various forms of generics. I’ve even been paid to write Haskell code! That said, I was pretty happy with Go without generics.
- maxwell86 5y ago
  You can just verify using any language with powerful optimizations and whose generic system supports both boxed and unboxed generics, e.g., Rust. The difference between passing an unboxed generic and triggering monomorphization vs passing a boxed type-erased generic is night and day in terms of performance.\ Boxed generics generate one version of the code that need to work for all types, independently of layout, and dispatch via the generic ABI (aka `interface {}` in Go). Unboxed generics generate one version of the code per type, removing memory allocations, and allowing the compiler to optimize the function for each type and each layout independently. This increases code size and compilation times, but in many cases allows dozens of compiler optimizations that aren't possible for the boxed generic case. The code produced by these optimizations allow others to run, etc. And a 100x improvement in perf isn't uncommon (i've seen order of magnitude larger improvements and regressions in perf than that from switching back and forth between boxed and unboxed generics in Rust).
  - ogogmad 5y ago
    Let me wade in: I think what you're saying is plausible, because the CPU cache should be an important variable here. Boxing should cause cache misses.
    - 5y ago
anothernewdude 5y ago
If only they'd had them from the beginning and not bolted them on
- blowski 5y ago
  Then we probably wouldn't have had Go for the last decade, and we wouldn't have all the real world use cases to guide a correct implementation of generics. "Get it completely right the first time" has never happened in the history of software.

jpgvm 5y ago

Exactly. Go was (still is tbh) slow. that is why these improvements are possible. Fast is relative ofc but if you are going to introduce the words "low level" in your description then don't be surprised when C/C++/Rust rear their ugly (but very fast) heads.

preseinger 5y ago
> Go was (still is tbh) slow. "Slow" isn't an objective metric. Slow how?
- jpgvm 5y ago
  It's less that it isn't objective but more that it's relative. As I mentioned in my original comment once you start throwing around the expression "low-level language" or "systems language" you invite comparisons to C/C++/Rust. Thus you will end up with a list of points like this: It makes less efficient use of hardware due to poor vectorization and lack of JIT to take advantage of this information which would be apparent at runtime. Namely escape analysis would be particularly good. I imagine that Go on Graal would be a very very fast language if time was invested there. Also until recently generics weren't a thing so it made it impossible to do -high performance- generic data-structures without code-gen. They were possible, but slow as balls due to interface{} and reflection. It's garbage collector is mediocre for latency, nothing impressive. But it's straight dog shit for throughput. Definitely not -fast- compared to JVM/Hotspot/ZGC. So, on the good side of Go it provides easy/good access to primitive types and primitive arrays of said types so as long as you know what you are doing you can generally massage the compiler into doing something not completely stupid. That said if I want to write really fast code in something that isn't C/C++/Rust I would much prefer Java or C#... or more logically if FAST is the primary concern then I would probably pick C++ or Rust.
  - preseinger 5y ago
    > It's garbage collector is mediocre for latency, nothing impressive. Go's GC is best-in-class for latency. What makes you think otherwise?
    - jpgvm 5y ago
      It's on par with other latency optimized GCs for pure pause time but because it's architecture pays a gigantic throughput cost making it only a mediocre GC overall. ZGC puts out the same pause numbers with monstrous throughput in comparison.

foldr 5y ago

Even in these microbenchmarks it’s not 10x. Boxing can be faster or slower depending on the context. For example, if the objects you are storing are large, unboxing them (rather than storing pointers to them) could well make the queue perform worse, as extending the arrays will require more memory to be copied. There’s no doubt that the unboxing permitted by (Go’s) generics will sometimes lead to better performance. But I think that the article is exaggerating. > TBH it's 2022 and it seems that "Go" devs are just seeing fire for the first time in their lives. Come on, let’s keep this patronizing and flamey kind of commentary off HN. I for one am a language nerd who’s tried plenty of languages with various forms of generics. I’ve even been paid to write Haskell code! That said, I was pretty happy with Go without generics.

maxwell86 5y ago
You can just verify using any language with powerful optimizations and whose generic system supports both boxed and unboxed generics, e.g., Rust. The difference between passing an unboxed generic and triggering monomorphization vs passing a boxed type-erased generic is night and day in terms of performance.\ Boxed generics generate one version of the code that need to work for all types, independently of layout, and dispatch via the generic ABI (aka `interface {}` in Go). Unboxed generics generate one version of the code per type, removing memory allocations, and allowing the compiler to optimize the function for each type and each layout independently. This increases code size and compilation times, but in many cases allows dozens of compiler optimizations that aren't possible for the boxed generic case. The code produced by these optimizations allow others to run, etc. And a 100x improvement in perf isn't uncommon (i've seen order of magnitude larger improvements and regressions in perf than that from switching back and forth between boxed and unboxed generics in Rust).
- ogogmad 5y ago
  Let me wade in: I think what you're saying is plausible, because the CPU cache should be an important variable here. Boxing should cause cache misses.
  - 5y ago

anothernewdude 5y ago

If only they'd had them from the beginning and not bolted them on

blowski 5y ago
Then we probably wouldn't have had Go for the last decade, and we wouldn't have all the real world use cases to guide a correct implementation of generics. "Get it completely right the first time" has never happened in the history of software.