Practices for writing high-performance Go • Hacker News Board

Re: Practices for writing high-performance Go

#41

Post by networkimprov » Mon, May 06, 2019, 6:52 PM UTC

shereadsthenews wrote: post #35

networkimprov wrote: post #29

Earlier quoted context omitted.

Is there a Github issue for this problem? If not, would you consider filing one? https://github.com/golang/go/issues It should probably explain why one cannot "avoid its global allocator" by using pools and/or stack objects.

Stack is great, then you will spend more time in runtime.morestack because the Go authors have wisely decided that we are all too dumb to request specific stack sizes and we must rely on copying and doubling stacks larger than 2KiB even if we know in advance that 2KiB is not enough. This compares poorly with native threads where the stacks are dynamically allocated one page at a time without copying and we can specif…

My point is that you should file a Github issue if there isn't one.

Re: Practices for writing high-performance Go

#42

Post by Thaxll » Mon, May 06, 2019, 7:02 PM UTC

derefr wrote: post #30

Thaxll wrote: post #22

Earlier quoted context omitted.

You're talking a about a very specific scenario, out of the box Go is off course easier than C++ for concurrency. Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks.

> Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks. Graph analysis and/or routing, for one. Distributed Dijkstra is pretty impractical (the optimal lower bound on the number of messages required equals the number of edges in the graph!) For example, I don't work for Google, but I can pretty much guarantee you that an individual Google Maps routi…

I highly doubt Google runs any workload on Borg with CPU count > 24. I don't work there, so I'm just assuming but it goes against all modern scaling / deployments patterns.

Re: Practices for writing high-performance Go

#43

Post by tensor » Mon, May 06, 2019, 7:30 PM UTC

erik_seaberg wrote: post #36

wbl wrote: post #15

Earlier quoted context omitted.

For a company with supposedly high hiring standards. Granted domain knowledge also matters but that isn't what the people described have. So what does Google teach them?

Everyone I met there had my respect. I find "not capable of understanding a brilliant language" to be baseless contempt and I'm surprised he didn't get more heat over it. I wouldn't work with him, nor whatever people he's trying in vain to accommodate.

That's really quite ironic given: https://news.ycombinator.com/item?id=19825787

Re: Practices for writing high-performance Go

#44

Post by Thaxll » Mon, May 06, 2019, 7:31 PM UTC

rightbyte wrote: post #38

Thaxll wrote: post #24

Earlier quoted context omitted.

High performance is a very vague terms now days, there are company that have Google scale problems that don't use C++ as main language ( Nerflix Uber ect ) any modern runtime can do "high performance" especially for backend applications. YouTube primary language is Python for instance.

Netflix OK but Uber? They did 4 billions rides in 2017. Thats naivly about 130 rides per second with nice parallelism due to locality of the physical rider. That's not an insane amount of data crunching.

You could say the same for Netflix, it's a giant CDN so why do they need 150k ec2 instances?

The problem they solve looks simple on the outside, the reality is different.

https://eng.uber.com/managing-data-workflows-at-scale/

Re: Practices for writing high-performance Go

#45

Post by lenkite » Mon, May 06, 2019, 8:09 PM UTC

shereadsthenews wrote: post #16

adrianN wrote: post #12

Earlier quoted context omitted.

Concurrency is a bit easier in Go than in C++.

Disagree. I can write a server in C++ that, with careful thought and a bit of planning, will be able to exploit the resources of the kind of 88-core dual-socket machines that are mainstream today. No amount of planning will allow me to write a Go program that does the same thing on the same machine. Small amounts of concurrency might seem easy in Go but lots of concurrency is hard.

Could you describe how you would go about designing this and what libraries/frameworks would you use ? AFAIK co-routines is only coming with C++ 20, so I guess you would still use std::thread right ?

Re: Practices for writing high-performance Go

#46

Post by shereadsthenews » Mon, May 06, 2019, 9:31 PM UTC

Thaxll wrote: post #42

derefr wrote: post #30

Earlier quoted context omitted.

> Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks. Graph analysis and/or routing, for one. Distributed Dijkstra is pretty impractical (the optimal lower bound on the number of messages required equals the number of edges in the graph!) For example, I don't work for Google, but I can pretty much guarantee you that an individual Google Maps routi…

I highly doubt Google runs any workload on Borg with CPU count > 24. I don't work there, so I'm just assuming but it goes against all modern scaling / deployments patterns.

There are various workloads that occupy entire machines, they are all very carefully written by dedicated performance experts, in C++.

Re: Practices for writing high-performance Go

#47

Post by kasey_junk » Mon, May 06, 2019, 9:38 PM UTC

legohead wrote: post #2

Thanks for this, I just started getting into and writing Go code. I have a question that I don't remember being answered in any tutorial I've done so far. I've written a lot of C code and I typically make memory managed lists, so if I need a new common object I grab one from the list to avoid free/malloc as much as possible. Does Go do this automatically, or should I still do this on my own? I'm writing a long-runnin…

I’ve written them myself & used sync.pool. I’d carefully test where you are using them though as I’ve had an instance where an implementation went from lots better to lots worse than the naive allocation due to escape analysis getting better across a golang version upgrade.

Re: Practices for writing high-performance Go

#48

Post by kasey_junk » Mon, May 06, 2019, 9:41 PM UTC

derefr wrote: post #30

Thaxll wrote: post #22

Earlier quoted context omitted.

You're talking a about a very specific scenario, out of the box Go is off course easier than C++ for concurrency. Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks.

> Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks. Graph analysis and/or routing, for one. Distributed Dijkstra is pretty impractical (the optimal lower bound on the number of messages required equals the number of edges in the graph!) For example, I don't work for Google, but I can pretty much guarantee you that an individual Google Maps routi…

Where do you get high core count computers that aren’t numa?

Re: Practices for writing high-performance Go

#49

Post by naikrovek » Mon, May 06, 2019, 9:45 PM UTC

weberc2 wrote: post #33

ryanworl wrote: post #4

Earlier quoted context omitted.

That is still a useful tool in Go, but you don’t need to use it as much as you’d think. The GC is pretty good at short-lived objects. The canonical implementation is sync.Pool if you don’t want to build one yourself.

Usually I use pools to avoid the allocation cost. The GC sweep is not usually my problem.

Profile it and see if it is a problem in Go, I would say.

I don't know if the Go runtime has optimizations for this kind of thing inherently, and it might.

Profile, and see.

Re: Practices for writing high-performance Go

#50

Post by IOT_Apprentice » Mon, May 06, 2019, 9:49 PM UTC

erik_seaberg wrote: post #36

wbl wrote: post #15

Earlier quoted context omitted.

For a company with supposedly high hiring standards. Granted domain knowledge also matters but that isn't what the people described have. So what does Google teach them?

Everyone I met there had my respect. I find "not capable of understanding a brilliant language" to be baseless contempt and I'm surprised he didn't get more heat over it. I wouldn't work with him, nor whatever people he's trying in vain to accommodate.

Yikes I think he is arguing against overwhelming programmers with complexity and the ability to hammer themselves with pointers, leaks and other banes of existence for average C programmers.