
Go devel compile times below 2x Go 1.4.3 - danieldk
https://groups.google.com/d/msg/golang-dev/DpMyPbclI3o/pKgtsx_BCQAJ
======
MustardTiger
How is the compiler for such a simplistic language so slow? The optimizing
ocaml compiler is 5-10x faster, and is compiling a much more advanced
language, complete with features developed in the 1970s even.

~~~
lobster_johnson
I don't doubt that OCaml is faster — but how do you know this to be true? Are
there benchmarks comparing equivalent programs in Go and OCaml?

In this particular case, the discussion is about a program that imports around
500 package dependencies and is compiling everything (as I understand it) from
scratch, resulting in a binary that is around 90MB.

~~~
MustardTiger
>Are there benchmarks comparing equivalent programs in Go and OCaml?

Yes. Go was nearly as bad as java and C++ in 2014, and it has gotten nearly
twice as slow since then. And yet "compiler performance" is the excuse for not
having generics. While C++ and java both have them and are now faster than
go's compiler, and ocaml is way faster and has them.

[http://forum.nim-lang.org/t/682](http://forum.nim-lang.org/t/682)

~~~
lobster_johnson
> Yes.

Please do provide them.

The notion that Go's compiler is slower than C++ is ridiculous. Go's compiler,
despite the recent slowdown, is still famously fast, whereas C++'s notorious
header file problem means that even small changes can trigger huge recompiles
(which is exacerbated by the fact that templates must often have their
implementation code in the header file, not the implementation file).

Meanwhile, Rust's compiler is much, much slower than Go's, and probably not
much faster than GCC/Clang with C++.

~~~
MustardTiger
I just linked to one in the post you replied to. And it shows clearly that
2014 go is almost as bad as C++ and java.

~~~
lobster_johnson
That's a _runtime_ benchmark, not a compile-time one.

Sure, the Nim post includes compile times, but no information about
benchmarking methodology; warm caches? How many runs? Percentiles? etc. Also,
the program being tested is just a few dozen lines (75 in Go, 73 in C++). Not
exactly exercising compilation speed here.

~~~
MustardTiger
It is both, hence both numbers being listed. "I don't like that evidence" is
not an argument. You asked if I had evidence, I provided it. If you still want
to believe go is not slow, then you provide evidence.

~~~
lobster_johnson
The link you provided is not evidence, just an anecdote. It's not that I don't
"like it"; it's absolutely not an indicator of anything real. At best it's an
indication that all compilers have some startup overhead, some more or less
than others. Based on JVM startup time alone, I could "prove" that Java was
the slowest language in the world.

The burden is on you to provide evidence, since it is your claim. Likewise,
benchmarks to support the claim that OCaml's compiler is faster.

I develop in Go daily, and nothing I've seen indicates that Go is anywhere
close to approaching C++ in compilation slowness. (I have also worked
extensively with C++.)

~~~
MustardTiger
>The link you provided is not evidence, just an anecdote

No it is not. A reproducible test is evidence, not anecdote.

>At best it's an indication that all compilers have some startup overhead,
some more or less than others. Based on JVM startup time alone, I could
"prove" that Java was the slowest language in the world.

That seems unlikely since we just saw otherwise.

>The burden is on you to provide evidence, since it is your claim

And I did. Dismissing it because it does not fit your preconceptions does not
mean I need to continue supplying more and more evidence for you to dismiss
without any justification.

>I develop in Go daily, and nothing I've seen indicates that Go is anywhere
close to approaching C++ in compilation slowness. (I have also worked
extensively with C++.)

Now _that_ is an anecdote.

~~~
lobster_johnson
Again, it's not evidence. There's _zero_ documentation about how the benchmark
was done. Was it repeated? Is the timing "best of N", or a percentile? Was
there warmup? And so on.

The compile times are _only_ shown in the Nim board comment, not the Github
page, which doesn't benchmark compilation times. Again, where did the numbers
come from?

Secondly, again, it was for a ~70-line program. Do you seriously think that
benchmarking the compilation of a 70-line program is statistically valuable?
It's ridiculous.

You completely missed the point of my JVM comment. Actually, I'm going to
assume you're trolling. I'll stop here.

~~~
MustardTiger
>Again, it's not evidence.

Repeating that will not make it so. The code is available, it is fully
documented and reproducible. That is not an anecdote.

>The compile times are only shown in the Nim board comment, not the Github
page, which doesn't benchmark compilation times. Again, where did the numbers
come from?

So? Evidence does not become anecdote simply because you dislike the source.
It doesn't need to be on github. It is where it is because the person who did
it put it there.

>Secondly, again, it was for a ~70-line program. Do you seriously think that
benchmarking the compilation of a 70-line program is statistically valuable?

If you want to make the argument that it is weak evidence then do so. But your
insistence on dishonestly claiming evidence is anecdote is not constructive.

>You completely missed the point of my JVM comment

No I did not, I pointed out that it is nonsense.

>Actually, I'm going to assume you're trolling. I'll stop here.

The laziest cop out possible. Baseless "troll" accusations do not belong in
real conversations. Make an effort to contribute.

------
apeace
EDIT: This is incorrect, see reply below.

> since gri's switched to making binary export/import the default, and a few
> followups from khr the time to build jujud compared to 1.4.3 is now solidly
> below 2x

If anyone else is curious like I was, I believe this is referring to a recent
Go change [1] which was previously discussed on HN [2].

However, I can't find the corresponding commit in the Juju repo.

[1]
[https://github.com/golang/go/commit/af6aa0fd745d48c2db70712e...](https://github.com/golang/go/commit/af6aa0fd745d48c2db70712ebfe6833d30a9a85d#diff-
ed59a16ce24322f4a023f5af3845333eR530)

[2]
[https://news.ycombinator.com/item?id=11593663](https://news.ycombinator.com/item?id=11593663)

~~~
Zariel
The change referred to is Robert Griesemer's change to use a new binary export
format [0]

[0]
[https://github.com/golang/go/commit/7538b1db8ec0d82a623847fe...](https://github.com/golang/go/commit/7538b1db8ec0d82a623847fe5987f1988fe16448)

~~~
apeace
Thank you!

------
foepys
Why is the default Go compile command (go build) only single-threaded and is
always compiling everything from scratch? That has always been my biggest
issue with Go and they didn't even fix this with the switch to a pure Go
compiler.

~~~
Goranek
use go install to cache packages

------
feylikurds
I am very critical of this assertion. I am currently developing a multiplayer
game with websockets in Go, and the compile times do not at all seem to be
less than 1.4. I am using 1.6.

~~~
CJefferson
The headline is confusing. It says the slowdown is now less than twice!

------
nedsma
I did recently (using Go 1.5) a comparison between three major development
platforms using almost the same hardware. Go compilation times were best on
OSX 10.11, followed by Ubuntu 15 and Win 8.1, all x64 systems. Anyone observed
the same?

------
pjmlp
Yeah, but from the forum discussion it is 139 seconds for compiling 512
packages!

Compiling a C or C++ project with 512 translation units would probably take
enough time to prepare a full meal.

