Go devel compile times below 2x Go 1.4.3 | Hacker News Reader

Go devel compile times below 2x Go 1.4.3

groups.google.com

31 pointsmicrotonal21 comments

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.

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.

>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

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

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.

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.

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.

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

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

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.

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

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

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

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

Thank you!

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.

use go install to cache packages

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.

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

read what the post said. less than twice the compile times of 1.4, and that's for tip, not 1.6. 1.6 is way worse.

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?

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.

Reply on news.ycombinator.com