Live data from Hacker News

Compile Go programs 7x faster

github.com

21–30 of 30 posts

Re: Compile Go programs 7x faster

#21
post #15

This is basically a wrapper for 'go install'. See this post / linked blog posts for an explanation why this is faster/useful: https://twitter.com/davecheney/status/697171533215576064

After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't be…

I have to echo everything said by @jerf. One additional suggestion is to write a blog post highlighting ways to improve the workflow for go developers and help them to understand why certain things are better than others, as your work here slots in nicely.

You could also explain in detail what goes on behind the scenes in an incremental build.

Re: Compile Go programs 7x faster

#23
post #15

This is basically a wrapper for 'go install'. See this post / linked blog posts for an explanation why this is faster/useful: https://twitter.com/davecheney/status/697171533215576064

After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't be…

You flagged _the story_, on HN? Don't do that. It's valuable if only as a hook for comments like yours.

Re: Compile Go programs 7x faster

#24
post #15

This is basically a wrapper for 'go install'. See this post / linked blog posts for an explanation why this is faster/useful: https://twitter.com/davecheney/status/697171533215576064

After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't be…

The length of code of a program should not be a metric for how useful or valid it is.

This is a great shortcut for something that I've been doing manually for years and I'm happy to have stumbled on it and the surrounding discussion. Please don't flag stories like this.

Re: Compile Go programs 7x faster

#25
post #23
post #15

Earlier quoted context omitted.

After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't be…

You flagged _the story_, on HN? Don't do that. It's valuable if only as a hook for comments like yours.

The "it could create good comments" is not a good metric for not flagging something, because there is no link for which that is not true, or at least someone would argue for it.

While I again want to emphasize I'm not really being that critical of the author for creating it, because people are welcome to put whatever they want on github, it's a thin piece of content whose thin content is also somewhat misleading, that was upvoted to the top of HN. I'm still comfortable with this, barring the admin staff disagreeing with me.

Re: Compile Go programs 7x faster

#26
post #18

Did not think compiling Go programs was that much of an issue. Many texts reference the fact that the whole standard library can be compiled in sub 10sec.

Since they've switched to a Go compiler from the previous C one, compile times have been pretty terrible.

They are still quite good comparing with C and C++ code bases, usually measured in hours for a "make world".

Apparently there are some optimizations coming up on newer versions.

Re: Compile Go programs 7x faster

#28
post #25
post #23

Earlier quoted context omitted.

You flagged _the story_, on HN? Don't do that. It's valuable if only as a hook for comments like yours.

The "it could create good comments" is not a good metric for not flagging something, because there is no link for which that is not true, or at least someone would argue for it. While I again want to emphasize I'm not really being that critical of the author for creating it, because people are welcome to put whatever they want on github, it's a thin piece of content whose thin content is also somewhat misleading, tha…

That's true for off-topic stories, which stories are the actual purpose of the flag button. It's not true for stories we simply disagree with. In this case, you happen to be right, but everyone has a bunch of topics they believe themselves to be right about.

Re: Compile Go programs 7x faster

#29
post #19
post #16

Earlier quoted context omitted.

Does `go build` use multiple core's?

There's a flag for it, which didn't make a difference (edit - with the new 1.7 compiler it does, but it goes from half that speed to the same figure). Even with a perfect scaling, I'd be about 10x behind a post from 7 years ago. Perhaps it's compiling a lot more lines than I think? Lots of bits of the standard library I should be including in the line count?

actually I guess stdlib is compiled, too. But golang before 1.5 was faster to compile. I just wonder how much difference it would make with multicore's. I mean scala beats down my new Xeon E5-2670 workstation on all threads.

Re: Compile Go programs 7x faster

#30
post #18

Did not think compiling Go programs was that much of an issue. Many texts reference the fact that the whole standard library can be compiled in sub 10sec.

Since they've switched to a Go compiler from the previous C one, compile times have been pretty terrible.

What was the delta, though? Generally graphs comparing version to version seem pretty okay.
Post reply on HN