4 ms·
Go’s GC is extremely low latency and you can pretty easily avoid allocating using the same techniques as you would in C++.
by weberc2 8y ago
Go’s GC is extremely low latency and you can pretty easily avoid allocating using the same techniques as you would in C++.
- crowhack 8y agoHow low latency are we talkin? 1ms , 10ms ?
- tptacek 8y agoSub-millisecond STWs. https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
- crowhack 8y agoThanks for this link.
- acln 8y agoSub-1ms STW pauses, even for very large heaps.
- NikolaeVarius 8y agohttps://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote Seems like it can go sub 1ms
- pcwalton 8y agoYou can't avoid allocating using the same techniques as in C++. In Go you have to know the intricacies of escape analysis to avoid allocation: objects are heap allocated "by default" and sometimes optimized to be stack allocated. In C++ there is no implicit heap allocation and usually no need for escape analysis. As a practical example, capturing variables in a closure will usually cause them to be heap allocated in Go, but in C++ capturing has no effect on variable storage.
- nullstyle 8y agoIt seems to me that you're not really taking a charitable interpretation of GP's comment. For example, in my game development experience (granted, I'm 6 years removed from that industry) we often relied on object pools to avoid allocation. You don't need to know anything about Go's escape analysis to use a pool to avoid allocation, as far as I can tell. Could you explain your position further?
- pcwalton 8y agoGo language constructs allocate in ways that are not immediately obvious. So using object pools is not sufficient to avoid allocation in Go as compared to, say, C++. In my view (which is the dominant view among compiler engineers for GC'd languages), spending a lot of effort to avoid allocation is a poor use of programmer time in a GC'd language. It is better to just improve the GC to make allocation fast. In a properly designed generational GC like that of Java HotSpot, allocation is about 5 instructions. That is a game changer: allocation is as cheap as a function call plus the prologue. Unfortunately, Go's designers have so far not deployed generational GC, which is why we keep having these threads about avoiding allocation. (I've seen indications in the last couple of weeks that Go may finally be moving to a generational GC, though, and I hope they do.)
- pjmlp 8y agoAnyone doing HTML 5/Flash like games in Go doesn't need to worry like if they are writting the next Fortnight in Vulkan.