A new ProtoBuf generator for Go • Hacker News Board

Re: A new ProtoBuf generator for Go

#71

Post by pjmlp » Fri, Jun 04, 2021, 6:21 AM UTC

mcronce wrote: post #56

somethingwitty1 wrote: post #54

Earlier quoted context omitted.

was the double-negative intentional? I've used Go for sub-millisecond needs. So 20ms seems like it would be a reasonable choice from where I'm sitting.

It was not intentional, thanks for asking...very unfortunate typo ;) Go doesn't give you control over inline vs indirect allocation, instead relying on escape analysis, which is notoriously finicky. Seemingly unrelated changes, along with compiler upgrades, can ruin your carefully optimized code. This is especially heinous because it uses a GC; unnecessary allocations have a disproportionately large impact on your ap…

While escape analysis in Go is finky, you can make it part of the CI/CD to keep it under control.

https://medium.com/a-journey-with-go/go-introduction-to-the-...

No different than running other kinds of static analysis for well known languages, unsafe by default.

Re: A new ProtoBuf generator for Go

#72

Post by PostThisTooFast » Fri, Jun 04, 2021, 6:43 AM UTC

PostThisTooFast wrote: post #2

Is there one for Kotlin yet? It's pretty pathetic that Google's own protocol lacks native support for its most popular operating system.

Where are the other fucking comments? Like the ones pointing out that Kotlin support was absent as late as 2019?

Eat shit, Hacker News.

Re: A new ProtoBuf generator for Go

#73

Post by jcelerier » Fri, Jun 04, 2021, 7:31 AM UTC

pjmlp wrote: post #70

jcelerier wrote: post #59

Earlier quoted context omitted.

> If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. okay, you've done this, three years later and it's the same thing again since you need to accomodate the new features. your users haven't upgraded their computers. what do you do ?

Run a profiler and optimize again.

Your original code is already optimized as much as is possible outside of the things mentioned by OP

Re: A new ProtoBuf generator for Go

#74

Post by nly » Fri, Jun 04, 2021, 8:31 AM UTC

sa46 wrote: post #62

Funny timing, I've just written most of a TypeScript generator for protobufs. I learned about some fun corners of protobufs I didn't expect trying to pass the protouf conformance tests [1] (which this one passes, that's no mean feat!). - If you write the same message multiple times, protobuf implementations should merge fields with a last write wins policy (repeated fields are concatenated). This includes messages in…

The varint format also isnt as dense on average as it could be and allows for non-canonical encodings. I.e. you can encode any integer in multiple ways (up to 9 or 10 bytes)

The solution for this is to subtract 1 from the integer every time you encode a byte (since the existence of the next byte you're adding already indicates that the intermediate value isn't 0)

Re: A new ProtoBuf generator for Go

#75

Post by pjmlp » Fri, Jun 04, 2021, 9:26 AM UTC

jcelerier wrote: post #73

pjmlp wrote: post #70

Earlier quoted context omitted.

Run a profiler and optimize again.

Your original code is already optimized as much as is possible outside of the things mentioned by OP

Don't guess, measure.

Then just like C, writing a tiny set of functions in Assembly is always an option.

Re: A new ProtoBuf generator for Go

#76

Post by jcelerier » Fri, Jun 04, 2021, 10:31 AM UTC

pjmlp wrote: post #75

jcelerier wrote: post #73

Earlier quoted context omitted.

Your original code is already optimized as much as is possible outside of the things mentioned by OP

Don't guess, measure. Then just like C, writing a tiny set of functions in Assembly is always an option.

Keep in mind that I am referring to this:

> If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC.

> Don't guess, measure.

yes, I am saying that the original code has already gone through a complete optimization process, everything is written in written in assembly, and you are at 970us on your 1ms time budget. (I'm not pulling those out of thin air, I was literally at a client yesterday with some real-time code with a 1ms deadline on a desktop OS and we have to cram as much things as possible in that millisecond)

Re: A new ProtoBuf generator for Go

#77

Post by pjmlp » Fri, Jun 04, 2021, 10:42 AM UTC

jcelerier wrote: post #76

pjmlp wrote: post #75

Earlier quoted context omitted.

Don't guess, measure. Then just like C, writing a tiny set of functions in Assembly is always an option.

Keep in mind that I am referring to this: > If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. > Don't guess, measure. yes, I am saying that the original code has already gone through a complete optimization process, everything is written in written in assembly, and you are at 970us on your 1ms time budget. (I'm not pulling those out of thin air, I was litera…

Well in that case there is no way around upgrading the hardware, a 486 won't play a MP4 no matter how hand tuned the Assembly code is.

Re: A new ProtoBuf generator for Go

#78

Post by 35fbe7d3d5b9 » Fri, Jun 04, 2021, 5:41 PM UTC

torbital wrote: post #67

sagichmal wrote: post #64

Earlier quoted context omitted.

Depending on workload, Go also does sub-1ms p99 pretty easily. I'm getting sub-1ms p99.9.

What are the proposed solutions to get better than that? C/Rust code? Assembly?

Going fast is one thing. Making a program that responds consistently is different, and there's a continuum of choices. The last time I read about Go's GC they targeted 500us and for tons of applications that's more than sufficient; for some, it's not.

You could start with twiddling some of the GC knobs Go gives you, but you're still working against an SLO. If you need stronger guarantees you'll look at languages that completely eschew GC, because Go's GC still has STW bits. Climb the ladder further and you're reducing allocations, eventually avoiding any malloc() beyond what it takes to get an arena and doing your own bookkeeping. I've never been near the top of the ladder when you have hard real-time constraints, but I've heard it involves paying Wind River for VxWorks licenses ;)