
Go compiler: Initial support for concurrent backend compilation - giovannibajo1
https://go-review.googlesource.com/c/40693/
======
eloff
Roughly 40% better compilation speed. Nice. Performance numbers from the
bottom of the CL:

All benchmarks are from my 8 core 2.9 GHz Intel Core i7 darwin/amd64 laptop.

First, going from tip to this CL with c=1 costs about 3% CPU and has almost no
memory impact.

Comparing this CL to itself, from c=1 to c=2 improves real times 20-30%, costs
5-10% more CPU time, and adds about 2% alloc.

From c=1 to c=4, real time is down ~40%, CPU usage up 10-20%, alloc up ~5%

Going beyond c=4 on my machine tends to increase CPU time and allocs without
impacting real time.

~~~
izym
Your CPU has 4 cores, but 8 threads due to Hyper-threading. It's quite normal
that not all programs will benefit from the additional threads. It would be
interesting to see how the compiler performs on more physical cores.

~~~
cbhl
Compiling programs is usually one of the cases that does benefit from filling
all the hyperthreads, though? That's why people often cargo cult running "make
-j<cores * 2>".

~~~
chrisseaton
In case other people don't see why this would be the case, hyperthreads are
good for running a second thread while the first one stalls while waiting for
something such as a memory read. Compilers often work with indirect data
structures such as irregular graphs and symbol tables which don't cache
perfectly and may cause memory stalls.

~~~
aarongolliver
It mattered more with spinning disks, you could basically pipeline disk reads
with optimization passes.

------
_ph_
This is not only a nice enhancement to the Go compiler and thus for all Go
users, but also it shows why Go as a language is so relevant. Single thread
performance of processors has not increased very much in the recent years,
while the core count continued to grow - I just configured a 20 core 40 thread
Xeon workstation and got prices between $4k and 5k.

Go is a great language which combines C-like speeds for low-level code with a
good concurrency model, making your program comparatively easy to parallelize
on a per-function basis. As the work on the Go compiler shows, it is not
trivial for complex programs, but definitely possible.

~~~
rbehrends
Compilation is not a good example of this, though. Parallel compilation is
something that any language that allows for separate compilation has supported
for decades (make -j N at its most basic, with some language implementations
providing more sophisticated support).

~~~
burntsushi
Go has supported that too. But this particular change enables parallelism
within a single compilation unit.

------
ridiculous_fish
Taking a thread-oblivious program and making it multithreaded can be very
hard. It requires global transitive knowledge of the function call graph and
all shared data structures.

How was this achieved? Was it by a dev who was intimately familiar with the
code base? Was it just applying the race detector repeatedly until it stopped
squawking? Something else?

~~~
bradfitz
> Was it by a dev who was intimately familiar with the code base? Was it just
> applying the race detector repeatedly until it stopped squawking?

Both.

------
azinman2
Details on the CL are a little thin, and the "don't believe the hype"
indicates this isn't automatically some big win. Can someone give more
details?

~~~
gpm
A reason I've heard against parallelizing compilers is that you get
parallelism for free in large builds as your build system will build separate
code-gen units (files in C, crates in rust, I believe in go it's packages)
that don't depend on eachother in parallel anyways. Adding it to the compiler
as well just creates synchronization overhead.

~~~
DSMan195276
I would agree. Basically all decent build systems will allow you to compile
units that aren't dependent on each other in parallel. Threading the compiler
may provide some gains, but it's likely that for a good portion of your build
time your CPU is already fully utilized anyway (And without any locking
overhead).

I feel like the real gains would be with a threaded linker instead, but I
can't say I have any data to back that up. But I mean, you can't link until
everything is compiled, so presumably there are free CPU cores that could be
used.

~~~
uluyol
Go's compilation unit is a package, not a file. This limits the amount of
parallelism you can get compared to say C outside of the compiler. You have
bottleneck packages like the runtime which have to be compiled before other
packages, and in the case where you do incremental compilation you probably
only have a few packages to compile anyway. Some of this is briefly touched on
in the CL (see comments on the amount of concurrently that should be enabled),
and there are issues on the bug tracker that go into more detail.

------
0xFFC
I got very interested in Go recently, but I have question, how do you do your
debugging in Go? I am using VSCode, and although VSCode support for Go is the
best support between editors, but there is no official support for debugging ,
it seems.

~~~
skj
I don't want to pretend debuggers aren't useful...

But I haven't used a debugger in at least ten years. Production Go for the
past few.

I debug with good log messages.

Of course, not everyone's problems are exactly like mine, so I will believe
you if you say it's necessary for your situation.

~~~
baconizer
this reflects my team's experience, initially skilled programmers (from C#
mainly) complains almost hourly about lack of IDE features, in particular -
Debugging. 14 months in now with 9 major services in production, I hear no
more conversation on this, and still no one yet bothered to setup dlv.
'Breakpoints', to our surprises, is not actually indispensable. Also I noticed
positive cultural change around, we move faster and team talks about business
problem solving more than programming itself, to a point I believe rich
functionality IDE over complicated things we do here.

~~~
sjellis
> Also I noticed positive cultural change around, we move faster and team
> talks about business problem solving more than programming itself, to a
> point I believe rich functionality IDE over complicated things we do here.

I think that this point about team conversations is incredibly important.
Apart from Ruby, Go is the only language that I know where the technical
conversations seem to consistently focus on the problem at hand, rather than
coding concerns like the finer points of language features. The company that I
work for does both Ruby and C#, and the difference in the conversations around
the two is very noticeable.

------
ceocoder
unrelated question for any Googlers looking at this, I like how PolyGerrit has
an "Old UI" option at the bottom of the page. When I enabled PolyGerrit on my
internal gerrit instance that button did not show up, and docs were rather
sparse.

Question - is it possible to turn on PolyGerrit with ability to switch back to
Old UI in open source gerrit? I found the option to turn on PolyGerrit here[0]

[0] [https://groups.google.com/forum/#!msg/repo-discuss/3JjvqB-
mK...](https://groups.google.com/forum/#!msg/repo-discuss/3JjvqB-
mKDE/Py4YSuASBwAJ)

~~~
EricBurnett
I use [1]. Does this work for you? I'm not sure the exact criteria at play.

[1] [https://chrome.google.com/webstore/detail/gerrit-ui-
switcher...](https://chrome.google.com/webstore/detail/gerrit-ui-
switcher/fdjpjnlhaohkkbjnglcfehbmcmpojklf)

------
andrecl
Can someone explain the significance of this post?

~~~
twotwotwo
If you're compiling a package with lots of functions in it, Go can now have
multiple cores working concurrently on (much of the work of) compiling
different functions.

Go would already work on more than one _package_ at once, using multiple
processes, which helped big builds covering many packages (think building
Juju, Kubernetes, or Docker from scratch). The benefit here is in the common
situation where you make a change in one package and recompile: more of your
cores can be put to use getting that package rebuilt.

This is a changelist for review, after preliminary work to move state out of
globals, etc. If you click "Show more" it will show much more, including
discussion of the internals and wall- and CPU-time benchmark results.

------
dilap
where does this commit actually exist to try it out?

~~~
TheDong
See the link that says 'Download'? Click it for instructions on how to
checkout this CL.

~~~
dilap
That does it; thanks

