On Thu, Dec 22, 2016 at 8:05 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:46:50 > *Objet: *Re: Modern Garbage Collection (good article) > > 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. > > > yes, it's just an anecdote. > > > 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. > > > I don't think it's a good long term strategy for Go even if it can be a > good one for how Google uses Go now. > There are a lot of tools written in Go, docker/kubernetes are maybe the > poster children but for something like InfluxDB (disclaimer, they give me a > t-shirt :) ) it's worrying. > So what would you suggest to them? Obviously everyone would love high throughput and low latency, but realistically/practically speaking here. Also, Go isn't as heap obsessed as Java, so it seems like GC pressure should be lower there (or could be made lower without contorting code) - correct me if I'm wrong though. I don't know why InfluxDB chose Go. People building infrastructure/systems at that level should not use such languages/runtimes IMO. > > > 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. > > > Rémi > > > 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. > > -- > 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.
