4 ms·

I've always found Go programs to be more noisy straced than C or C++ ones. I wonder if it's less noisy internally at Google with their userspace threading? http

by mkj 4y ago

I've always found Go programs to be more noisy straced than C or C++ ones. I wonder if it's less noisy internally at Google with their userspace threading? https://lore.kernel.org/lkml/20200722234538.166697-1-posk@posk.io/ https://lore.kernel.org/lkml/20200722234538.166697-1-posk@po...

metadat 4y ago
Has any further progress been made in open sourcing this work?
ilyt 4y ago
It's no wonder really. It's asynchronous IO + thread pool serving currently available to run goroutine, it will run few threads even if code is just a single function calling other functions.
scottlamb 4y ago
> I wonder if it's less noisy internally at Google with their userspace threading? No, the Go runtime's the same outside and inside Google. The experience of writing concurrent code is pretty good, the performance is pretty good, and optimizing strace output would be nice but I think isn't at the top of the design priorities. There are also other nice tools for debugging Go, e.g. the built-in CPU, memory, and (iirc) lock contention profiling that are well-integrated with the runtime. Google's fibers library is C++-only, last I checked. It does help vs other userspace threading libraries in that the same kernel pid is used for the same task, but it's really similar to just threaded C++ otherwise. And typically programs using it still have event-driven threads, as well as fibers dedicated to particular requests, and the two styles do a lot of handoffs. metadat asked: > Has any further progress been made in open sourcing this work? Last I saw was https://lwn.net/Articles/879398/ https://lwn.net/Articles/879398/ and https://lore.kernel.org/linux-mm/E63F4045-E624-47FE-A417-5D2FF7923179@gmail.com/T/ https://lore.kernel.org/linux-mm/E63F4045-E624-47FE-A417-5D2... .
- scottlamb 4y ago
  Oh, this looks promising: https://lore.kernel.org/all/20221212210547.1105894-1-posk@google.com/ https://lore.kernel.org/all/20221212210547.1105894-1-posk@go... > We are in the process of finalizing UMCG internally, and I plan to post the patches here once all reviews/testing and some preliminary rollouts are done.

by mkj 4y ago

metadat 4y ago

Has any further progress been made in open sourcing this work?

ilyt 4y ago

It's no wonder really. It's asynchronous IO + thread pool serving currently available to run goroutine, it will run few threads even if code is just a single function calling other functions.

scottlamb 4y ago

> I wonder if it's less noisy internally at Google with their userspace threading? No, the Go runtime's the same outside and inside Google. The experience of writing concurrent code is pretty good, the performance is pretty good, and optimizing strace output would be nice but I think isn't at the top of the design priorities. There are also other nice tools for debugging Go, e.g. the built-in CPU, memory, and (iirc) lock contention profiling that are well-integrated with the runtime. Google's fibers library is C++-only, last I checked. It does help vs other userspace threading libraries in that the same kernel pid is used for the same task, but it's really similar to just threaded C++ otherwise. And typically programs using it still have event-driven threads, as well as fibers dedicated to particular requests, and the two styles do a lot of handoffs. metadat asked: > Has any further progress been made in open sourcing this work? Last I saw was https://lwn.net/Articles/879398/ https://lwn.net/Articles/879398/ and https://lore.kernel.org/linux-mm/E63F4045-E624-47FE-A417-5D2FF7923179@gmail.com/T/ https://lore.kernel.org/linux-mm/E63F4045-E624-47FE-A417-5D2... .

scottlamb 4y ago
Oh, this looks promising: https://lore.kernel.org/all/20221212210547.1105894-1-posk@google.com/ https://lore.kernel.org/all/20221212210547.1105894-1-posk@go... > We are in the process of finalizing UMCG internally, and I plan to post the patches here once all reviews/testing and some preliminary rollouts are done.