Forwarded from Daniel Lemire's blog
Go generics are not bad
When programming, we often need to write โgenericโ functions where the exact data type is not important. For example, you might want to write a simple function that sums up numbers. Go lacked this notion until recently, but it was recently added (as of version 1.18). So I took it out for a spin. In Java, generics work well enough as long as you need โgenericโ containers (arrays, maps), and as long as stick with functional idioms. But Java will not let me code the way I would prefer. Here is how I would write a function that sums up numbers: int sum(int[] v) { int summer = 0; for(int k = 0; k < v.length; k++) { summer += v[k]; } return summer; } What if I need to support various number types? Then I would like to write the following generic function, but Java wonโt let me. // this Java code won't compile static T sum(T[] v) { T summer = 0; for(int k = 0; k < v.length; k++) { summer += v[k]; }โฆ
https://lemire.me/blog/2022/07/08/go-generics-are-not-bad/
When programming, we often need to write โgenericโ functions where the exact data type is not important. For example, you might want to write a simple function that sums up numbers. Go lacked this notion until recently, but it was recently added (as of version 1.18). So I took it out for a spin. In Java, generics work well enough as long as you need โgenericโ containers (arrays, maps), and as long as stick with functional idioms. But Java will not let me code the way I would prefer. Here is how I would write a function that sums up numbers: int sum(int[] v) { int summer = 0; for(int k = 0; k < v.length; k++) { summer += v[k]; } return summer; } What if I need to support various number types? Then I would like to write the following generic function, but Java wonโt let me. // this Java code won't compile static T sum(T[] v) { T summer = 0; for(int k = 0; k < v.length; k++) { summer += v[k]; }โฆ
https://lemire.me/blog/2022/07/08/go-generics-are-not-bad/
๐บ๐ฆ Go performance channel
https://twitter.com/calebspare/status/1546928290123812864
Twitter
New #Go memory model seems to be like Java: no undefined behavior due to data races, only race conditions (all variables are atomic-ish). This inhibits lots of compiler optimizations C/C++ compilers typically do.
But races on strings/maps still lead to arbitraryโฆ
But races on strings/maps still lead to arbitraryโฆ
Nice #golang proposal by twitter.com/mbmcloughlin is accepted ๐:
testing: add Elapsed() method to testing.B
https://github.com/golang/go/issues/43620
testing: add Elapsed() method to testing.B
https://github.com/golang/go/issues/43620
X (formerly Twitter)
Michael McLoughlin (@mbmcloughlin) on X
Mathematical Software Engineer.
Mastodon @[email protected]
Bluesky @mmcloughlin.com
Mastodon @[email protected]
Bluesky @mmcloughlin.com
๐บ๐ฆ Go performance channel
Nice #golang proposal by twitter.com/mbmcloughlin is accepted ๐: testing: add Elapsed() method to testing.B https://github.com/golang/go/issues/43620
One more step to the better #golang benchmarks (now by twitter.com/mknyswe, also accepted ๐):
testing: report GC/op when b.ReportAllocs is called
https://github.com/golang/go/issues/52466
testing: report GC/op when b.ReportAllocs is called
https://github.com/golang/go/issues/52466
X (formerly Twitter)
mknyszek (@mknyswe) on X
works on @golang runtime | he/him
> Weโre all agreed that we want something platform-independent and vector-length agnostic. ARM is especially interested in it being vector-length agnostic because of new SVE instructions.
โค๏ธโ๐ฅ
Src: #golang compiler and runtime meeting notes (golang/go issue 43930)
โค๏ธโ๐ฅ
Src: #golang compiler and runtime meeting notes (golang/go issue 43930)
๐บ๐ฆ Go performance channel
> Weโre all agreed that we want something platform-independent and vector-length agnostic. ARM is especially interested in it being vector-length agnostic because of new SVE instructions. โค๏ธโ๐ฅ Src: #golang compiler and runtime meeting notes (golang/go issueโฆ
To be honest @Arm Memory Tagging Extension is also a hot thing but more about safety rather than performance.
๐บ๐ฆ Go performance channel
To be honest @Arm Memory Tagging Extension is also a hot thing but more about safety rather than performance.
Twitter
@go_perf @Arm There may be some applications for GCs. E.g. marking pointers to objects w/o pointers (don't need scanning) or encoding object size right in the pointer (for some common small sizes at least).
Things are getting interesting (#golang PGO for Go 1.20)