5 ms·
Layperson here: what is special about Go's runtime, aside from the GC?
by Hinrik 3mo ago
Layperson here: what is special about Go's runtime, aside from the GC?
- onlyrealcuzzo 3mo agoIt's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.
- deleted 3mo ago[deleted]
- jcgl 3mo agoThis is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?
- insanitybit 3mo agoI think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.
- Aurornis 3mo ago> n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons. Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway. The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.
- never_inline 3mo agoGo has few issues with performance (lack of in-line union types, interface overuse, inefficient idioms reg. collections, some missed optimizations) but its seems plausible for a idiomatic Go program to outperform an idiomatic rust program in some situations. Example: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284
- jandrewrogers 3mo ago> It's literally the most sophisticated scheduling engine in the world. That seems unlikely regardless of how good it is. This is a domain where state-of-the-art research is not in the public literature. Scheduling is an AI-complete problem.
- zacmps 3mo agoWhat benchmarks are you referring to? Rust itself doesn't have a scheduler of course, I assume this is comparing against tokio or one of the other async executors?
- insanitybit 3mo agoI think this is interesting and warrants explanation. There are cases where a GC can be faster (sort of, Arenas get you most of the gains) but "the most sophisticated scheduling engine in the world" should be easy to at least partially support.
- pjmlp 3mo agoWhat a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.
- dnautics 3mo agoErlang's scheduler is not sophisticated, which is what makes it AWESOME. but yeah. i would be surprised if the JVM's scheduler is not more sophisticated than go's if for no other reason than it has way more knobs you can tune. you know they put that knob in there because someone (probably Google cough cough) asked for it
- pjmlp 3mo agoThe missing part is that if what is in box isn't enough, both JVM and CLR allow you to fully customise how the scheduling algorithm works.
- fnord77 3mo agoGoroutines?
- djha-skin 3mo agoChief design goals were radically easy concurrency and speed of compilation.
- minraws 3mo agoSpeed of compilation feels like a distant second in terms of goals given the weird new generic features they keep adding.. I was fine with basic generics they complicated it quite a bit much for my liking.
- ameliaquining 3mo agoWhat weird new generic features? Generic type aliases? Those aren't very complicated.
- vips7L 3mo agoIs the Go GC that special? Is it even generational yet?
- silisili 3mo agoI'm not sure it would ever make sense to be. That makes the assumption tons of allocations get made that don't live long, which was(maybe is still?) more common in some languages. Go is more aggressive about not heap allocating, and has tools to help you avoid them.
- vips7L 2mo agoIt makes plenty sense to be. There aren’t many negatives and there are plenty of workloads that would benefit.
- Mawr 3mo agoIdk, is it? https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc > Is it even generational yet? Is there any reason in particular it should be? Or are you just throwing random buzzwords around? Anyways, https://github.com/golang/go/discussions/70257#discussioncomment-11201305 https://github.com/golang/go/discussions/70257#discussioncom...
- vips7L 3mo agoYou seem to be really hostile for no apparent reason. There are plenty of reasons to be generational, there are lots of workloads that the current implementation might fall flat if it wasn't.