Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new ProtoBuf generator for Go

vitess.io

Post reply on HN
Print view View original

11–20 of 78 posts

Re: A new ProtoBuf generator for Go

#11

Post by harikb »

morelisp wrote: post #6
jeffbee wrote: post #5

Earlier quoted context omitted.

Proto message unmarshal in Go for a small message should be 5 orders of magnitude below 20ms, shouldn't even begin to matter until you are sweating individual microseconds.

Until the GC kicks in and steals a full 200usec + a bunch of your throughput... (Holy shit, who is downvoting this? It's literally the whole article!)

Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$

Re: A new ProtoBuf generator for Go

#13

Post by morelisp »

harikb wrote: post #11
morelisp wrote: post #6

Earlier quoted context omitted.

Until the GC kicks in and steals a full 200usec + a bunch of your throughput... (Holy shit, who is downvoting this? It's literally the whole article!)

Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$

Yeah, the whole point of the article is that gRPC v2 (and frankly v1 for that matter) are not “properly written” to do this.

Re: A new ProtoBuf generator for Go

#14

Post by pjmlp »

shoefindortz wrote: post #12

> Arenas are, however, unfeasible to implement in Go because it is a garbage collected language. If you are willing to use cgo, google already implemented one for gapid. https://github.com/google/gapid/tree/master/core/memory/aren...

Not only that, there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to touch any C code.

There is still so much education to do.

Re: A new ProtoBuf generator for Go

#15

Post by jen20 »

I'm not sure that the phrasing in the article is particularly fair:

> The maintainers of Gogo, understandably, were not up to the gigantic task.

I'm 99% sure they are "up to" (as in "capable of") doing so, they are just not "up for" it (as in, "will not do it").

Re: A new ProtoBuf generator for Go

#16

Post by RhodesianHunter »

harikb wrote: post #11
morelisp wrote: post #6

Earlier quoted context omitted.

Until the GC kicks in and steals a full 200usec + a bunch of your throughput... (Holy shit, who is downvoting this? It's literally the whole article!)

Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$

>or even Java

Just in case you may be unaware, the latest GCs for Java (Shenandoah, ZGC) are miles ahead of anything available for Go due to sheer age and manpower. Parallel and Pauseless are easily achievable in most cases.

Re: A new ProtoBuf generator for Go

#17

Post by jupp0r »

Using CPU utilization as a performance metric can be extremely misleading. My favorite article on the subject is from Brendan Gregg:

http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-...

A much better way to test the influence of the new compiler would be to test the actual throughput at which saturation is achieved (which is what the benchmark in the C++ grpc library measure to assess their performance).

Re: A new ProtoBuf generator for Go

#18

Post by morelisp »

RhodesianHunter wrote: post #16
harikb wrote: post #11

Earlier quoted context omitted.

Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$

>or even Java Just in case you may be unaware, the latest GCs for Java (Shenandoah, ZGC) are miles ahead of anything available for Go due to sheer age and manpower. Parallel and Pauseless are easily achievable in most cases.

Java's GC is better but Go's GC is also parallel and "pauseless" - iirc ZGC is 50-500usec which is comparable to Go's target 200usec.

The point is, neither is "five orders of magnitude" below 20ms. And neither needs zero CPU even if it doesn't block other threads.

Re: A new ProtoBuf generator for Go

#19

Post by p_l »

pjmlp wrote: post #14
shoefindortz wrote: post #12

> Arenas are, however, unfeasible to implement in Go because it is a garbage collected language. If you are willing to use cgo, google already implemented one for gapid. https://github.com/google/gapid/tree/master/core/memory/aren...

Not only that, there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to touch any C code. There is still so much education to do.

Aren't arenas old news in GC languages in general?

Most of the time, their non-presence is due to general pools being just as good most of the time, or people simply not needing them that much with modern GC

Re: A new ProtoBuf generator for Go

#20

Post by dimitrios1 »

pjmlp wrote: post #14
shoefindortz wrote: post #12

> Arenas are, however, unfeasible to implement in Go because it is a garbage collected language. If you are willing to use cgo, google already implemented one for gapid. https://github.com/google/gapid/tree/master/core/memory/aren...

Not only that, there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to touch any C code. There is still so much education to do.

I can't believe we've managed to have this lengthy of a discussion about GC languages and speed without anyone mentioning rust. Has HN turned a corner?
Post reply on HN