4 ms·

Great article, just skimmed it, but will definitely dive deeper into it. I thought Go is doing full monomorphization. As another datapoint I can add that I tri

Great article, just skimmed it, but will definitely dive deeper into it. I thought Go is doing full monomorphization. As another datapoint I can add that I tried to replace the interface{}-based btree that I use as the main workhorse for grouping in OctoSQL[0] with a generic one, and got around 5% of a speedup out of it in terms of records per second. That said, compiling with Go 1.18 vs Go 1.17 got me a 10-15% speedup by itself. [0]:https://github.com/cube2222/octosql https://github.com/cube2222/octosql

morelisp 5y ago
> That said, compiling with Go 1.18 vs Go 1.17 got me a 10-15% speedup by itself. Where did you see this speedup? Other than `GOAMD64` there wasn't much in the release notes about compiler or stdlib performance improvements so I didn't rush to get 1.18-compiled binaries deployed, but maybe I should... (I do expect some nice speedups from using Cut and AvailableBuffer in a few places, but not without some rewrites.)
- cube2222 5y ago
  I've experienced that speedup on an ARM MacBook Pro. I've just checked on Linux AMD64 and there's no performance difference there.
  - hencq 5y ago
    It's probably because of the new register passing calling convention. From https://tip.golang.org/doc/go1.18 https://tip.golang.org/doc/go1.18 > Go 1.17 implemented a new way of passing function arguments and results using registers instead of the stack on 64-bit x86 architecture on selected operating systems. Go 1.18 expands the supported platforms to include 64-bit ARM (GOARCH=arm64), big- and little-endian 64-bit PowerPC (GOARCH=ppc64, ppc64le), as well as 64-bit x86 architecture (GOARCH=amd64) on all operating systems. On 64-bit ARM and 64-bit PowerPC systems, benchmarking shows typical performance improvements of 10% or more.
  - ptomato 5y ago
    Yeah, 1.17 got register (instead of stack) calling convention on amd64; 1.18 expanded that to arm64, which should be responsible for most of that performance improvement.
- coder543 5y ago
  GOAMD64 could be significant, so I'm not sure why your comment seems to dismiss it? Also, as the article mentions, Go 1.18 can now inline functions that contain a "range" for loop, which previously was not allowed, and this would contribute performance improvements for some programs by itself. The new register-based calling convention was extended to ARM64, so if you're running Go on something like Graviton2 or an Apple Silicon laptop, you could expect to see a measurable improvement from that too. (edit: the person you replied to confirmed they're using Apple Silicon, so definitely a major factor.) The Go team is always working on performance improvements, so I'm sure there are others that made it into the release without being mentioned in the release notes.
  - morelisp 5y ago
    > GOAMD64 could be significant, so I'm not sure why your comment seems to dismiss it? Because it's not just upgrading from 1.17 to 1.18, you actually need to set it. Also because I ran a bunch of our code's benchmark suites, including a rather large set of custom serdes, and saw no improvements. Even some of the synthetic benchmarks used to introduce the new optimizations are below 10%. Hopefully it'll grow in scope over the next few versions.

morelisp 5y ago

> That said, compiling with Go 1.18 vs Go 1.17 got me a 10-15% speedup by itself. Where did you see this speedup? Other than `GOAMD64` there wasn't much in the release notes about compiler or stdlib performance improvements so I didn't rush to get 1.18-compiled binaries deployed, but maybe I should... (I do expect some nice speedups from using Cut and AvailableBuffer in a few places, but not without some rewrites.)

cube2222 5y ago
I've experienced that speedup on an ARM MacBook Pro. I've just checked on Linux AMD64 and there's no performance difference there.
- hencq 5y ago
  It's probably because of the new register passing calling convention. From https://tip.golang.org/doc/go1.18 https://tip.golang.org/doc/go1.18 > Go 1.17 implemented a new way of passing function arguments and results using registers instead of the stack on 64-bit x86 architecture on selected operating systems. Go 1.18 expands the supported platforms to include 64-bit ARM (GOARCH=arm64), big- and little-endian 64-bit PowerPC (GOARCH=ppc64, ppc64le), as well as 64-bit x86 architecture (GOARCH=amd64) on all operating systems. On 64-bit ARM and 64-bit PowerPC systems, benchmarking shows typical performance improvements of 10% or more.
- ptomato 5y ago
  Yeah, 1.17 got register (instead of stack) calling convention on amd64; 1.18 expanded that to arm64, which should be responsible for most of that performance improvement.
coder543 5y ago
GOAMD64 could be significant, so I'm not sure why your comment seems to dismiss it? Also, as the article mentions, Go 1.18 can now inline functions that contain a "range" for loop, which previously was not allowed, and this would contribute performance improvements for some programs by itself. The new register-based calling convention was extended to ARM64, so if you're running Go on something like Graviton2 or an Apple Silicon laptop, you could expect to see a measurable improvement from that too. (edit: the person you replied to confirmed they're using Apple Silicon, so definitely a major factor.) The Go team is always working on performance improvements, so I'm sure there are others that made it into the release without being mentioned in the release notes.
- morelisp 5y ago
  > GOAMD64 could be significant, so I'm not sure why your comment seems to dismiss it? Because it's not just upgrading from 1.17 to 1.18, you actually need to set it. Also because I ran a bunch of our code's benchmark suites, including a rather large set of custom serdes, and saw no improvements. Even some of the synthetic benchmarks used to introduce the new optimizations are below 10%. Hopefully it'll grow in scope over the next few versions.