3 ms·
Downvote because 5 minutes is absurd as a STW GC time, for ANY gc language. Heck, I wouldn't accept 5 minute lag in a python prototype. Even in the dewey eyed
by kortex 6y ago
Downvote because 5 minutes is absurd as a STW GC time, for ANY gc language. Heck, I wouldn't accept 5 minute lag in a python prototype.
Even in the dewey eyed early years, Go saw STW latency in the hundreds of milliseconds. By 1.8 it's in the hundreds of microseconds.
Your hard-real-time is out the window as soon as routing and UDP is involved. The intent is "real time bounded by the amount of time it would take doctors to react to a code blue (heart issue/failure". One second of reaction (thousands of gc's, dozens of health checks, a near eternity in program time) isn't going to make a difference when human reaction time latency is hundreds of milliseconds.
Call it "live streaming" if that sounds more objective, but conceptually if the clients (humans) don't perceive a difference in state, it's real time (to them).
Save the milliseconds-hard-real-time talk for rockets and cars.
https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
https://www.reddit.com/r/golang/comments/aetba6/gcs_stw_pauses_in_go112_beta_are_much_shorter/ https://www.reddit.com/r/golang/comments/aetba6/gcs_stw_paus...
- andi999 6y agoI agree with the absurd for any gc language, but doesnt mean it is not happening: https://plumbr.io/blog/garbage-collection/revealing-the-length-of-garbage-collection-pauses https://plumbr.io/blog/garbage-collection/revealing-the-leng... Would love to see a worst case analysis for go though. (My worry is, that long running applications are more prone to extensive gc stw, since os starts to swap pages, and gc tries to access them, might take a while) Of course if you can guarantee that go always has stw gc for less than a second (or even 10 seconds) that would be great (and make go a hard real time language, of course not a very fast one)