Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: build the cgo artifacts for each package in parallel #9887

Open
petermattis opened this issue Feb 16, 2015 · 9 comments
Open

cmd/go: build the cgo artifacts for each package in parallel #9887

petermattis opened this issue Feb 16, 2015 · 9 comments
Labels
Milestone

Comments

@petermattis
Copy link

@petermattis petermattis commented Feb 16, 2015

The lack of parallelization for compilations within a single package doesn't matter too much when building go files, but does affect cgo compilation. I have a package with about 32k lines of (generated) C++. Compiling it serially takes ~10.5s. A small hack to cmd/go/build.go to compile C/C++/Obj-C files in parallel brings this down to ~3.7s.

The patch I hacked together to parallelize cgo compilation work is ~50 lines of deltas and is mostly contained in builder.cgo().

PS The compilation times above were measured using go 1.4.1 on Mac OS X, but this code hasn't changed at head and similar compilation times can be seen there.

@minux minux changed the title "go build" doesn't parallelize compilations within a package cmd/go: "go build" doesn't parallelize compilations within a package Feb 16, 2015
@robpike

This comment has been minimized.

Copy link
Contributor

@robpike robpike commented Feb 16, 2015

Seems reasonable to me. Why not send the patch?

@petermattis

This comment has been minimized.

Copy link
Author

@petermattis petermattis commented Feb 16, 2015

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Apr 25, 2015

CL https://golang.org/cl/4931 mentions this issue.

@petermattis

This comment has been minimized.

Copy link
Author

@petermattis petermattis commented Mar 30, 2016

I'm curious if there is any plan to parallelize cgo compilation for go1.7. The finer-grained work scheduling for go tool actions mentioned in https://go-review.googlesource.com/#/c/4931/ would be great if it ever happens, though it doesn't look like there is any movement on that front.

@bcmills bcmills changed the title cmd/go: "go build" doesn't parallelize compilations within a package cmd/go: build the cgo artifacts for each package in parallel Jan 23, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Jan 23, 2019

Contrast #21605. Are there any similar ordering issues for other languages?

@bcmills bcmills added the ToolSpeed label Jan 23, 2019
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 23, 2019

Currently we only support C, C++, and Fortran, and C and C++ have no ordering issues.

I'm not aware of ordering issues for any other language.

@r0l1

This comment has been minimized.

Copy link

@r0l1 r0l1 commented Dec 19, 2019

Any updates on this? Compiling one of our packages takes around 30 seconds...
Would be great, if cgo compilation could be parallelized.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Dec 19, 2019

@r0l1, this issue is milestoned to Unplanned, meaning that we do not currently plan to work on it.

The previous CL was closed in favor of “implementation of finer-grained actions”, which I think may be #8893.

@mvdan

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented Jan 7, 2020

I had a brief look at this last week, because this is causing an annoying build time bottleneck in a project of mine. I assume the file we're interested in is src/cmd/go/internal/work/exec.go.

In particular, the Builder.cgo method makes calls to Builder.gcc synchronously in a loop.

It's unclear to me how we'd fix this, though. Can anyone point me to a doc that explains how work.Action is designed at a high level?

For example, I can imagine these ways to fix the issue, but it's unclear which would be the right one:

  • In Builder.cgo, create a child Action for each gcc call, and ensure they're all run before we continue (is this possible?)
  • Before the entire cgo method is called via build, separate the work into a tree of actions (how? cfiles is constructed as part of cgo, for example)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.