Compiler speed and data-driven design

605 views
Skip to first unread message

ben...@gmail.com

unread,
Dec 8, 2021, 5:25:08 PM12/8/21
to golang-dev
I recently watched the talk by Andrew Kelley (creator of Zig) on data-driven design with the case study of speeding up the Zig compiler: https://media.handmade-seattle.com/practical-data-oriented-design/ ... he got 20% reduction in wall clock time in the tokenizer/AST creation, and 40% reduction in wall clock time in the IR generation by using these techniques. Pretty significant!

I'm wondering how much of this kind of data-driven design (struct/data packing, struct-of-arrays vs array-of-structs layout, avoiding pointers, and so on) has been applied to the Go compiler?

I just read the "Introduction to the Go compiler" (https://github.com/golang/go/tree/master/src/cmd/compile), and noted in particular this paragraph:

> The gc package includes an AST definition carried over from when it was written in C. All of its code is written in terms of it, so the first thing that the gc package must do is convert the syntax package's syntax tree to the compiler's AST representation. This extra step may be refactored away in the future.

This is src/cmd/compile/internal/noder, right? I don't know how much it slows things down, but it seems like it'd be a whole bunch of allocations/GC pressure. I'm curious why it's difficult to get rid of that? (Or maybe it's not difficult; it just hasn't been done? Though that seems unlikely. :-)

I'm also aware of this issue: https://github.com/golang/go/issues/49569 "cmd/compile: Go 1.18 compile time may be about 18% slower than Go 1.17 (largely from changes due to generics)" ... which indicates that there's another pass in Go 1.18, "noder2", to support generics. (Though I don't see a "noder2" package in the repo.)

Basically I'm curious what's been done already in terms of data-driven design, what appetite there is to do more of this (I realize some of it may make code less clear and simple). Any other pointers the compiler devs have to discussions about compiler speed would interest me too.

Thanks,
Ben

robert engels

unread,
Dec 8, 2021, 6:24:16 PM12/8/21
to ben...@gmail.com, golan...@googlegroups.com
Is compiler time really an issue with Go though? The language was designed in such a way (packages and linkages) to make this pretty darn fast for even the largest of projects.

Seems the effort in something like this would be better spent elsewhere.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/96e082cc-673d-4f47-95dc-3c7cb94820f4n%40googlegroups.com.

Rob Pike

unread,
Dec 8, 2021, 7:25:26 PM12/8/21
to robert engels, ben...@gmail.com, golan...@googlegroups.com
You're right, compiler speed isn't the reason it seems fast, not
really. That wasn't an explicit goal. There is a lot of misinformation
about compiler speed and Go's design.

The compiler isn't actually all that fast. I mean, it's OK, but it's
not superb, and it has slowed down significantly since the early days.
Compared to some other languages it may be a faster compiler, but
that's a tough comparison because of the next paragraph. And it's
certainly slower than some languages' too. (It wasn't designed to be
slow, either, but let's not go there.)

The real reason Go seems to compile quickly compared to other
languages is that we worried a lot about build time. Not compile time,
build time. Minimizing I/O during compilation, efficient algorithms
(due to efficient design) for package resolution. Having only one
source file for each item, as opposed to a .c and a .h for example, or
a separate types description file. Folding dependency information into
.o files. And so on.

I talked about these design details at length in
https://talks.golang.org/2012/splash.article.

-rob
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/EF8D65D8-F49F-4D45-9D85-8F52F896AEED%40ix.netcom.com.

Jon Forrest

unread,
Dec 10, 2021, 4:10:51 PM12/10/21
to golan...@googlegroups.com
On 12/8/21 4:25 PM, Rob Pike wrote:

> The compiler isn't actually all that fast. I mean, it's OK, but it's
> not superb

What would be required to make it superb?

Jon


ben...@gmail.com

unread,
Dec 12, 2021, 6:19:21 PM12/12/21
to golang-dev
Thanks for the replies. This is good context, and I'm really thankful for the design of Go that allows for such fast builds!

To answer Robert Engels' question, "is compiler time really an issue with Go though"? It's a fair question. In my case, I guess not really. I just like speed. :-) Even the big project I work on (github.com/juju/juju) compiles in less than two minutes after a "go clean -cache", and 5-10 seconds for an incremental build if you change a package that is not used by many things, or ~30 seconds if you change a core package that's imported by a lot of things. I'd say 10-15 seconds is typical for this project. Still more than I'd like, but definitely nothing to complain about for a project with over half a million lines of non-test code.

Would improving the speed of the compiler actually help end-to-end build times? It seems to me it would, as I suspect compile time is dominant in most cases (but it's possible link time is dominant for incremental builds, I'm not sure). What's the easiest way to measure this? Run the go compile and link stages manually and measure the time? Or can you get output like this from the go command?

Particularly with the compiler having slowed down with Go 1.18 and the release of generics (https://github.com/golang/go/issues/49569), I was thinking it'd be good to at least see what's been discussed before, or what's being planned. I'm personally interested in the "data-driven design" angle, but any other pointers would be useful too. I'm willing to help, but would love some pointers to send me off in the right direction. I'll also start profiling and post some results here if I don't get any replies -- I know folks are busy just getting 1.18 ready!

For what it's worth, for the Juju project, running "time make go-install" (which is basically a wrapped "go install") after a "go clean -cache" gives 1m39s on Go 1.17 (lowest of 5 runs), and 1m45s on gotip (Go 1.18), which is a 6% slowdown (time increase).

-Ben

Ian Lance Taylor

unread,
Dec 14, 2021, 7:21:40 PM12/14/21
to ben...@gmail.com, golang-dev
On Sun, Dec 12, 2021 at 3:19 PM ben...@gmail.com <ben...@gmail.com> wrote:
>
> Would improving the speed of the compiler actually help end-to-end build times? It seems to me it would, as I suspect compile time is dominant in most cases (but it's possible link time is dominant for incremental builds, I'm not sure). What's the easiest way to measure this? Run the go compile and link stages manually and measure the time? Or can you get output like this from the go command?

You can get an idea of the time required for each step of a build by running

go build -toolexec=/usr/bin/time PACKAGE

I would expect that link time is typically dominant for incremental
builds of a binary.

Ian

ben...@gmail.com

unread,
Dec 14, 2021, 7:40:06 PM12/14/21
to golang-dev
You can get an idea of the time required for each step of a build by running

go build -toolexec=/usr/bin/time PACKAGE

Thank you -- very helpful.

-Ben

Austin Clements

unread,
Dec 14, 2021, 9:15:14 PM12/14/21
to ben...@gmail.com, golang-dev
You may also be interested in looking at the work we did on the linker in Go 1.15 and 1.16, which is described at https://go.dev/s/better-linker. I'm sure there's further room for improvement, but we did get quite a bit of performance improvement, in part by redesigning the internal data layout of the linker.

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

Ben Hoyt

unread,
Dec 15, 2021, 11:39:26 AM12/15/21
to golang-dev
Ah yes, I did look at that at the time -- thanks for the reminder!
Reply all
Reply to author
Forward
0 new messages