Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.3 Linker Overhaul

docs.google.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Go 1.3 Linker Overhaul

#21

Post by 1631- »

microtonal wrote: post #19
singular wrote: post #13

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation tim…

> But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents.

As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.

Re: Go 1.3 Linker Overhaul

#22

Post by chimeracoder »

girvo wrote: post #12
coldtea wrote: post #8

Earlier quoted context omitted.

> Compile time is a big deal when you have millions of lines of code that constantly change and very expensive devs that are spending large amounts of time waiting. 1) Sure. Most of us do not. So why should we care and/or trade other stuff for compile time improvements? 2) That's when you don't have a module loading system and have to build everything everytime.

1) Cause the creators of the language decided to. Don't like it, feel free to fork it.

> Don't like it, feel free to fork it.

Or use gccgo, which piggybacks off of the many optimizations that have been used in the gcc collection[0] over the years.

When discussing compilation of Go, people here often seem to forget that two first-class compilers exist for the language.

[0] Yes, I am aware that this is like saying "ATM machine"

Re: Go 1.3 Linker Overhaul

#23

Post by microtonal »

1631- wrote: post #21
microtonal wrote: post #19

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation tim…

> But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents. As I've already said to someone else. This is about linking , not compilation . The rest of your comment is irrelevant to this discussion.

As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.

And I am reacting to your grandparent, who was talking about compilation.

Re: Go 1.3 Linker Overhaul

#24

Post by 1631- »

microtonal wrote: post #19
singular wrote: post #13

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation tim…

(I don't seem to be able to reply to your comment directly)

danieldk 8 minutes ago | link

>> As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.

> And I am reacting to your grandparent, who was talking about compilation.

I'm fairly certain that that slow compile time is a combination of `compile + link` and the linking is probably a big part of the equation as well, just like it is in C and Go.

Re: Go 1.3 Linker Overhaul

#25

Post by cpeterso »

singular wrote: post #13
coldtea wrote: post #6

Earlier quoted context omitted.

> tends to emphasize compile speed over producing optimal executables So they opted to handle the easy problem.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

Firefox build times are much faster than that. My MacBook Pro can build Firefox in 12 minutes, but other people can build everything in less than 8 minutes! :)

https://groups.google.com/d/msg/mozilla.dev.platform/HdXdNdf...

Re: Go 1.3 Linker Overhaul

#26

Post by singular »

cpeterso wrote: post #25
singular wrote: post #13

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

Firefox build times are much faster than that. My MacBook Pro can build Firefox in 12 minutes, but other people can build everything in less than 8 minutes ! :) https://groups.google.com/d/msg/mozilla.dev.platform/HdXdNdf...

Wow. I'm really impressed with that. I'm looking at >1hr on a mid-2012 Macbook Pro Retina for Chromium.

Re: Go 1.3 Linker Overhaul

#27

Post by singular »

1631- wrote: post #24
microtonal wrote: post #19

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation tim…

(I don't seem to be able to reply to your comment directly) danieldk 8 minutes ago | link >> As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion. > And I am reacting to your grandparent, who was talking about compilation. I'm fairly certain that that slow compile time is a combination of `compile + link` and the linking is probably a…

Absolutely, I should have said 'build' rather than 'compile'. It's both compilation and linking.

Re: Go 1.3 Linker Overhaul

#28

Post by singular »

microtonal wrote: post #19
singular wrote: post #13

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation tim…

> But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents.

Actually, chromium's ninja [0] build setup [1] is really awesome, and does what it can with incremental building, but it's obviously limited in what it can do, it doesn't seem to take very much to trigger a very big rebuild. It's a definite help though.

[0]:http://martine.github.io/ninja/ [1]:https://code.google.com/p/chromium/wiki/NinjaBuild

Re: Go 1.3 Linker Overhaul

#29

Post by stcredzero »

microtonal wrote: post #20
stcredzero wrote: post #18

Earlier quoted context omitted.

So they opted to handle the easy problem. Also the problem with the lowest cost/benefit for them. Also the problem with the highest benefit. One calls this a "no-brainer."

...or selling a shortcoming as a feature. What if someone picks up pcc[1] and claims it is better than the competition because it makes C compilation lightning-fast? Of course, Go is a language that is more amendable for quick compilations. But it would be more interesting to see a solution that provides good optimizations and improves programmer productivity. Go doesn't really have an answer to that (except: use gcc…

...or selling a shortcoming as a feature.

If you want to be nitpicky, it's not that Go is selling a shortcoming as a feature. It's more that it simply doesn't have that feature.

Go also has a number of other features pcc doesn't.

Re: Go 1.3 Linker Overhaul

#30

Post by stcredzero »

cpeterso wrote: post #25
singular wrote: post #13

Earlier quoted context omitted.

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-) I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

Firefox build times are much faster than that. My MacBook Pro can build Firefox in 12 minutes, but other people can build everything in less than 8 minutes ! :) https://groups.google.com/d/msg/mozilla.dev.platform/HdXdNdf...

Everything should happen in under 3 seconds. Once you get past that threshold, you get a qualitative change in development style.
Post reply on HN