tip compiler speed

I like to use tip to make sure all our stuff
still works there, but the compiler really
is quite a bit slower. How much speed improvement
can we hope for in Go 1.5 ?

Here's one example:

using go1.4.2:

% rm -r $GOPATH/pkg
% go-release go version
go version go1.4.2 linux/amd64
% time go-release go test -i
59.77user 11.08system 0:21.59elapsed 328%CPU (0avgtext+0avgdata
907840maxresident)k
43064inputs+348368outputs (7major+4004376minor)pagefaults 0swaps
% time go-release go test -c
5.74user 0.82system 0:06.65elapsed 98%CPU (0avgtext+0avgdata 862656maxresident)k
45056inputs+141240outputs (2major+320077minor)pagefaults 0swaps

using tip (b21ff39):

% rm -r $GOPATH/pkg
% go version
go version devel +b21ff39 Tue May 19 02:18:40 2015 +0000 linux/amd64
% time go test -i
217.04user 14.11system 1:17.14elapsed 299%CPU (0avgtext+0avgdata
1502748maxresident)k
13872inputs+373848outputs (61major+4461224minor)pagefaults 0swaps
% time go test -c
130.21user 8.25system 0:56.48elapsed 245%CPU (0avgtext+0avgdata
888336maxresident)k
120inputs+315560outputs (2major+2591109minor)pagefaults 0swaps

(to be fair, the 56.48 second case there seems to be an outlier;
the mode seems to be around 16s)

Thanks. A good motivator!

It's a total cop out, but if you have enough RAM running with GOGC=off
will probably be faster. The linker and I suspect the compiler are a
bad case for a mark & sweep gc: lots of small objects with pointers
between them, relatively few of which ever become garbage.
Alternatively, setting GOMAXPROCS=2 makes things a bit faster,
presumably because the GC can then do some of its mostly fruitless
marking in a separate thread.

Cheers,
mwh

I agree with Michael.

Notwithstanding the fantastic improvements to code gen and gc
performance that Russ, Rick, Keith, Dmitry and Austin have been doing,
the compiler is a poor fit for the gc because it creates an intricate
mesh of *Nodes, none of which are unreferenced until the end of the
program, but all of which must be scanned. This is all work that the
old 1.4 compilers didn't have to do because they did bump pointer
malloc'ing, and then let the OS clean up the mess when the program
exited.

Turning off the GC entirely sounds unattractive, but as *Nodes are
never expected to be freed, is there any consideration for allocating
them in a huge [nnn]Node in the bss (I know the linker currently gets
this wrong), or in off heap memory mmap'ed from MAP_ANON ?

Thanks

Dave
> --
> 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.

I suspect that this will not help (but have not tried and would love
to be wrong). Here's why:

Running the CPU profiler, 40% of the time is spent on the line
mcentral.go:217. This is setting up the freelist for newly allocated
spans. Perhaps this is an artifact of CPU profiling (?). If not, it
suggests that the compiler performance would be significantly improved
by making setting up new spans cheaper, perhaps by enabling an
alternative representation of spans that can cheaply represent n steps
of a fixed size in a row. Something vaguely like:

type gclink struct {
n int // number of remaining sequential pointers; 0 means use next instead
step uintptr // offset of next sequential pointer
next gclinkptr // next set of sequential pointers
}

I don't know enough about the memory allocator to know whether this
would help, how difficult it might be to implement, or what other
havoc it might wreak.

I did try the obvious thing of unrolling the loop 8x, and it
(probably) helped a tiny bit. Compiling the rotate0.go test, I saw a
borderline-significant speed-up of 1.37% (n=100, p=0.06). However, the
loop is memory-bound, not CPU-bound, so it is unsurprising that
unrolling wouldn't have much impact.

If this effect is not an artifact of CPU profiling, addressing it
might help all short-lived programs that allocate heavily and free
little.

-josh

Yup, that was me.

Message received and understood rob.

I tried a similar experiment. As well as batch allocating, I replaced
all instances of *Node with a 4-byte identifier. This has the downside
that a Node basically never stack allocates, and the upside that the
Node object is smaller for 6g.

Surprisingly the results are a wash. Timing go build -a std shows
results within 5% of tip.

The diff is enormous, so I won't bother uploading it.

I spent a little while poking at the linker, rather than the compiler.
I tried a few things -- trying to shrink LSym a couple of ways, by
replacing linked lists with slices (although hm, i didn't replace the
ones that get sorted by listsort), by combining boolean fields into a
flags field, optimizing for the version==0 case in Linklookup.
Nothing really made a significant difference and I won't bother
uploading the patches unless anyone is curious.

My observations:

1) Generating DWARF is slow (about 25% of runtime). I don't
understand this code at all and possibly there's some low hanging
fruit in there.
2) loading object files is slow (about 50% of runtime). We spend a
surprising amount of time (maybe 15% of runtime) in expandpkg!
3) Linklookup accounts for another 15% of runtime. Maaybe having a
symbol table and referring to symbols by index would be faster? Would
be a huge and very ugly change to do throughout the linker but maybe
it could work while loading an object file.

My unscientific feeling is that making the linker significantly faster
would require changing the object file format.

Hope these ramblings are useful/interesting.

Cheers,
mwh

One cheap but I suspect unpalatable fix is to not generate DWARF by
default. This would also considerably shrink binaries.
There are a ton of []byte/string conversions going on in that code,
many of them unnecessary. Changing to use []byte more thoroughly would
help; I started on that but the change metastasized. And using
bytes.Replacer (golang.org/issue/9905) in expandpkg could speed it up
considerably. All too involved for 1.5, though, and I maintain hope
that cmd/newlink will make all this code obsolete one day.

-josh

I am very saddened to hear this suggestion.

--
Aram Hăvărneanu