It's hard to interpret anecdotes for more than just that - an anecdote :). Rewrites in general tend to be better (for some definition of better, performance included) even if done in the same language.
But, I think as a *principle* of favoring lower latency at the cost of throughput is the right choice for them and how they see Go being used. Mind you, I'm not a fan nor a user of Go so I'm referring purely to their stipulated strategy on how to evolve their GC. On Thu, Dec 22, 2016 at 7:37 AM Remi Forax <fo...@univ-mlv.fr> wrote: > > > ------------------------------ > > *De: *"Vitaly Davidovich" <vita...@gmail.com> > *À: *mechanical-sympathy@googlegroups.com > *Envoyé: *Jeudi 22 Décembre 2016 13:12:00 > *Objet: *Re: Modern Garbage Collection (good article) > > FWIW, I think the Go team is right in favoring lower latency over > throughput of their GC given the expected usage scenarios for Go. > > In fact, most of the (Hotspot based) Java GC horror stories involve very > long pauses (G1 and CMS not excluded) - I've yet to hear anyone complain > that their "Big Data" servers are too slow because the GC is chipping away > at throughput too much (most of those servers aren't CPU bound to begin > with or can't become CPU bound due to bottlenecks elsewhere). > > > As an anecdote, in my lab, the only go program we had was a program that > optimizes on the fly a huge homemade RDF store depending on most the > frequent queries. It was re-written in Java by a Phd student last > September. Maybe it was slow because of the Go GC avoiding long pauses, but > from the perspective of the team leader, it was just that Go was too slow > (and getting slower at each release). > > In the Hotspot world, there's also the unfortunate situation right now > where G1 isn't really solving any problem nor advancing the performance > (latency) boundaries. In fact, it taxes throughput quite heavily (e.g. > significantly more expensive write barriers) but isn't breaking any new > ground. > > > Rémi > > > > On Wed, Dec 21, 2016 at 11:38 PM Zellyn <zel...@gmail.com> wrote: > > You might be interested in this Golang-group follow-up thread too… > https://groups.google.com/forum/#!topic/golang-nuts/DyxPz-cQDe4 > (naturally a more pro-Go > take on things…) > > On Wednesday, December 21, 2016 at 8:23:02 AM UTC-5, Greg Young wrote: > > Thought people on here would enjoy this > > > > https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.ptdzwcmq2 > > > > > > -- > > > Studying for the Turing test > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > email to mechanical-sympathy+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > -- > Sent from my phone > > > > > -- > > > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > email to mechanical-sympathy+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > email to mechanical-sympathy+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
