FAQ
Linking juju is now ~5 seconds, so I think it is safe to focus on the compiler.

For the compiler, it turns out pprof can merge profiles, which means
that adding:

         gcargs = append(gcargs, "-cpuprofile", ofile+".prof")

to func (gcToolchain) gc in cmd/go, then building juju with -work
gives you a set of profiles you can merge with:

         go tool pprof -proto -output=/tmp/juju.prof
../pkg/tool/darwin_amd64/compile $(find $WORK -name \*.prof)

It looks something like the the attached SVG. Definitely GC-dominated,
but the graph gives up several interesting compiler functions.
On Tue, Mar 8, 2016 at 3:33 AM, Rob Pike wrote:
Yes, we have established that a full build takes longer, but does any
component of the build add disproportionately? Compiling? Linking? One big
package? Many packages? These broad numbers (which I admit I contributed to)
only confirm the existence of an issue, they do nothing to narrow down what
it might be.

Since juju shows the worst ratio, I think that's the one to look at. We
expect everything to be linear, but something is clearly not.

-rob

On Tue, Mar 8, 2016 at 7:11 PM, wrote:

Some more numbers with gc on and off for me. On tip I tried playing with
the ssa check flags, but it didn't make any difference for me, maybe i was
misusing the flags though.

1.6:

ac@black:~/src/benchjuju$ ./benchjuju.bash
go version go1.6 linux/amd64

real 1m0.099s
user 2m45.420s
sys 0m6.476s


GOGC=off
ac@black:~/src/benchjuju$ ./benchjuju.bash
go version go1.6 linux/amd64

real 0m38.019s
user 1m22.640s
sys 0m9.468s

tip:
ac@black:~/src/benchjuju$ ./benchjuju.bash
go version devel +beabd87 Tue Mar 8 06:02:15 2016 +0000 linux/amd64

real 1m2.182s
user 2m48.584s
sys 0m6.092s


GOGC=off
go version devel +beabd87 Tue Mar 8 06:02:15 2016 +0000 linux/amd64

real 0m43.500s
user 1m39.920s
sys 0m9.196s


On Tuesday, March 8, 2016 at 8:39:20 PM UTC+13, Dave Cheney wrote:

I don't believe Juju is atypical. It's only notable quality is the
girth of the dependency graph that goes into a single binary, which
makes it useful because it brings compile and link times into human
scales.

As an experiment I built a test set from another large open source
project and ran the same tests for a command with 304 dependent
packages.

1.4.3

real 0m29.428s
user 1m19.825s
sys 0m10.983s


real 0m31.618s
user 1m26.436s
sys 0m11.854s


real 0m31.474s
user 1m26.892s
sys 0m12.298s

tip (beabd872f43)

real 1m36.218s
user 5m21.163s
sys 0m12.090s


real 1m38.975s
user 5m31.432s
sys 0m12.091s


real 1m39.403s
user 5m33.396s
sys 0m12.276s

This shows the same 3x increase in real time, and a smaller 3.7x
increase, vs the 4.5x for benchjuju, in user time.

You can find the dataset here,
https://github.com/davecheney/benchkube. I have no preference which
data set to use, I think they are both good data sets for benchmarking
the compiler.

Thanks

Dave
On Tue, Mar 8, 2016 at 6:01 PM, Rob Pike wrote:
That seems surprising to me, since other significant programs do not
see a
4.5x increase.

I'll stop belaboring the obvious but for one last time: juju is pushing
harder than other programs and it may be possible both to understand
how and
to do something about it. Isn't that why you posted the graph?

Where is the CPU time going? Measure it somehow, profile it, run top
while
building, use time -a, whatever it takes. Try not linking. Try only
linking.
Try building individual packages. I don't know what to try but I know
there's lots that has not been reported being tried.

-rob

On Tue, Mar 8, 2016 at 2:50 PM, Dave Cheney wrote:

The user time going from 1.4.3 is 99 seconds to 429 seconds, roughly a
4.5x increase. Given that there are now 4x Go processes, each running
their
own gc, which thinks it has exclusive access to all four logical
processes,
this does not seem surprising to me.
On Tue, Mar 8, 2016 at 2:43 PM, Rob Pike wrote:

This is well known, and is believed to be most of the cause of the
advertised 2X slowdown when the compiler was moved from C to Go. But
juju is
seeing a larger factor.

-rob


On Tue, Mar 8, 2016 at 2:20 PM, Konstantin Shaposhnikov
wrote:
FYI turning off GC can actually decrease compilation times
(especially
user time):

$ go version

go version go1.6 linux/amd64

$ time go build -a std

real 0m6.569s
user 0m27.592s
sys 0m2.719s

$ time GOGC=off go build -a std

real 0m5.583s
user 0m12.872s
sys 0m3.597s
On Mar 8, 2016 10:26 AM, "Rob Pike" wrote:

The large spike in user over real is perhaps explained by large
memory,
which would take lots of GC time in Go (and none in 1.4, in C),
that is
compensated for by more CPUs being on by default (done partly to
make up the
difference).

If that hypothesis is correct, we need to find the few files whose
compilations are causing so much memory to be consumed.

-rob

On Tue, Mar 8, 2016 at 12:27 PM, Rob Pike wrote:

107 packages from multiple places, nothing too dramatic, but we
should
be talking about juju not my test that isn't so bad.

-rob


On Tue, Mar 8, 2016 at 12:02 PM, Dave Cheney <da...@cheney.net>
wrote:


On Tue, Mar 8, 2016 at 12:00 PM, Rob Pike <r...@golang.org>
wrote:
However I am misinterpreting the graph, there are numbers on it
that
are worse than I can reproduce in my own code base, which means
juju is
causing worse performance.

How many packages are there in your example set ? How deeply are
they
nested ? How wide does the dependency graph fan out ? Juju does
all three of
these with aplomb.

And yes, it's user time I'm upset by on the graph, but real time
in
real life. I have been unclear.

However you slice it, things are too slow.

-rob


On Tue, Mar 8, 2016 at 11:02 AM, Dave Cheney <da...@cheney.net>
wrote:
I'm sorry, I still don't see a 10x increase in real time. From
43
seconds (go 1.4.3) to 139 seconds (go 1.5.3) is just over 3x.

On Tue, Mar 8, 2016 at 10:59 AM, Rob Pike <r...@golang.org>
wrote:
I am looking at real time, because that is what we wait for.

-rob


On Tue, Mar 8, 2016 at 10:58 AM, Dave Cheney
<da...@cheney.net>
wrote:
I don't know where this 10x increase in user time you quote
is
coming from

version 1.4.3real00:00:43
user00:01:39
sys00:00:17
version 1.5.3real00:02:19
user00:07:05
sys00:00:24
version 1.6real00:02:09
user00:06:35
sys00:00:20
rev 6ed1038real00:02:11
user00:06:39
sys00:00:19

I count that as 4.6x increase in user time going from go
1.4.3 to
1.5.3.

On Tue, Mar 8, 2016 at 10:52 AM, Rob Pike <r...@golang.org>
wrote:
I just did a simple check using a completely stable,
unedited
program of a few tens of thousands of lines. Here are the
results (go build
is running at today's tip):

% time go build -gcflags=-ssa=0

real 0m4.585s
user 0m5.570s
sys 0m1.027s
% time go build -gcflags=-ssa=1

real 0m5.778s
user 0m7.201s
sys 0m1.102s
% time go build -gcflags='-ssa=1 -d=ssa/check/off'

real 0m5.371s
user 0m6.707s
sys 0m1.137s
% time go1.4 build

real 0m2.631s
user 0m2.286s
sys 0m0.670s
%

As you can see, the 2X number sounds about right. Cheney's
10X
seems pathological.

SSA costs about 20% relative to the old compiler.

All those factors ignore whatever setup and linking overhead
there might be and assume it's all in the compiler.


-rob


On Tue, Mar 8, 2016 at 10:28 AM, <andrewc...@gmail.com>
wrote:
iirc there were reports from people where the build time
went
up disproportionately high around 1.5, Here is one I
remember:

https://groups.google.com/forum/#!searchin/golang-nuts/build$20time$201.5/golang-nuts/39jJ8sW-qVY/m-5lI_f_VssJ
. Interesting the factor slowdown is similar, though maybe
totally
unrelated.

Anyone other than Dave actively looking into a cause?

On Tuesday, March 8, 2016 at 12:10:57 PM UTC+13, Dave
Cheney
wrote:
I've pushed the code into a stand alone repo so that
others
can verify my results, or just run your own benchmarks.

https://github.com/davecheney/benchjuju

Linking github.com/juju/juju/cmd/jujud is also a great
benchmark for the linker.

Thanks

Dave

On Tue, Mar 8, 2016 at 9:18 AM, Rob Pike <r...@golang.org>
wrote:
Some of it, yes, but how much? With other tests it
appears to
cost about 2X.

-rob


On Tue, Mar 8, 2016 at 9:14 AM, Ian Lance Taylor
wrote:
On Mon, Mar 7, 2016 at 1:57 PM, Rob Pike
<r...@golang.org>
wrote:
User time got almost 10X worse. I want to know why.
Some of it has to be the concurrent GC.

Ian
On Tue, Mar 8, 2016 at 8:50 AM, Dave Cheney
wrote:
The line I'm tracking is real time, which grew by
2.5x
after go 1.5.

I'll drop reporting the sys and user times on the
graph,
it is confusing.


On Tue, 8 Mar 2016, 08:46 Rob Pike, <r...@golang.org>
wrote:
Whatever the reason, it's almost a 10X slowdown,
much
worse than is
expected or is usually seen. I wonder if juju
tickles
some pathological
issue.

-rob


On Tue, Mar 8, 2016 at 8:44 AM, Rob Pike
wrote:
Ah, right. Well, the incipient drop in time should
continue then.

-rob


On Tue, Mar 8, 2016 at 8:39 AM, Brad Fitzpatrick
<brad...@golang.org>
wrote:
The peak is at Go 1.5.3, not post-Go1.6 SSA.


On Mon, Mar 7, 2016 at 1:36 PM, Rob Pike
wrote:
OK, but that means the peak is overly
pessimistic,
and I believe by a
substantial amount.

-rob


On Tue, Mar 8, 2016 at 8:32 AM, Dave Cheney
wrote:
It's just what is in tip at the time. The only
revisions that I
believe has the ssa checks enabled are the ones
post
1.6.

I intend to keep the chart updated over time.


On Tue, 8 Mar 2016, 08:27 Rob Pike,
wrote:
Dave C., do the times in that graph include the
SSA
compiler's
internal consistency checks? If so, it is an
unfair
chart. If not, it is a
sad chart.

-rob


On Tue, Mar 8, 2016 at 7:39 AM, Dave Cheney
wrote:
Just to follow up, a version of jujud compiled
with 1.3.3

-rwxr-xr-x 1 dfc dfc 88174297 Mar 7 20:43
jujud

and comparing that to one just compiled with
tip

-rwxrwxr-x 1 dfc dfc 79450868 Mar 7 12:44
/home/dfc/bin/jujud

Which looks like 10% reduction in binary size!


On Mon, Mar 7, 2016 at 9:44 PM, Dave Cheney
<da...@cheney.net>
wrote:
It's around 80mb. The improvements David
Crawshaw
made last week
have reduced the link times by 1/3rd.

In truth, I don't care about the binary size,
there is no way you
can compile 512 packages and have a small
binary,
we've just got far too
much code for that.

On 7 Mar 2016, at 21:41, Konstantin
Shaposhnikov
wrote:

It would be interesting to see size of the
created binary on the
same graph.

On Mar 7, 2016 6:26 PM, "Aram Hăvărneanu"
wrote:
I bought a new computer to work on Go,
because
compile times
became
unmanageable.

I'm willing to help in bringing the compile
performance back as
much as I can.

--
Aram Hăvărneanu

--
You received this message because you are
subscribed to the
Google Groups "golang-dev" group.
To unsubscribe from this group and stop
receiving emails from it,
send an email to
golang-dev+...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.

--
You received this message because you are
subscribed to the Google
Groups "golang-dev" group.
To unsubscribe from this group and stop
receiving
emails from it,
send an email to
golang-dev+...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are
subscribed
to the Google
Groups "golang-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send
an email to golang-dev+...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are subscribed
to
the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving
emails
from it, send an
email to golang-dev+...@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the
Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails
from
it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase