Go 1.3 Linker Overhaul
docs.google.com
Go 1.3 Linker Overhaul
1–10 of 33 posts
Re: Go 1.3 Linker Overhaul
#2Been a while since I looked at ELF but it would sure be nice if it used, say, a well-defined ELF subset to make use of the many ELF tools out there already.
Re: Go 1.3 Linker Overhaul
#3Been a while since I looked at ELF but it would sure be nice if it used, say, a well-defined ELF subset to make use of the many ELF tools out there already.
The article mentions that possibility.
Re: Go 1.3 Linker Overhaul
#4Interestingly, they want to do the opposite of what Microsoft did with their C++ compiler and linker. To enable "whole program optimizations" Microsoft's compiler writers added the intermediate code analysis, optimizations and code generation to the linker, allowing to, for example, if it is beneficial, inline function invocations for small functions that aren't declared as inline and that come from the different module. So their linker can now do both the classical linking (what Go authors have as the goal now) and the "linker does the code optimization, including intra-module, and generation."
Did Go ever use intra-modules optimizations in their linker? Do Go authors really find there's no need for that, when they want to fix the new object code format to only the "generated code" one?
Re: Go 1.3 Linker Overhaul
#5Interestingly, they want to do the opposite of what Microsoft did with their C++ compiler and linker. To enable "whole program optimizations" Microsoft's compiler writers added the intermediate code analysis, optimizations and code generation to the linker, allowing to, for example, if it is beneficial, inline function invocations for small functions that aren't declared as inline and that come from the different mod…
Go's gc toolchain (as opposed to gccgo) tends to emphasize compile speed over producing optimal executables, so they may be flat-out deciding to leave some potential whole-program optimizations on the table to for link speed--pure speculation, though. (And don't know re: your question.)
Re: Go 1.3 Linker Overhaul
#6Interestingly, they want to do the opposite of what Microsoft did with their C++ compiler and linker. To enable "whole program optimizations" Microsoft's compiler writers added the intermediate code analysis, optimizations and code generation to the linker, allowing to, for example, if it is beneficial, inline function invocations for small functions that aren't declared as inline and that come from the different mod…
Go's gc toolchain (as opposed to gccgo) tends to emphasize compile speed over producing optimal executables, so they may be flat-out deciding to leave some potential whole-program optimizations on the table to for link speed--pure speculation, though. (And don't know re: your question.)
>tends to emphasize compile speed over producing optimal executables
So they opted to handle the easy problem.
Re: Go 1.3 Linker Overhaul
#7Earlier quoted context omitted.
Go's gc toolchain (as opposed to gccgo) tends to emphasize compile speed over producing optimal executables, so they may be flat-out deciding to leave some potential whole-program optimizations on the table to for link speed--pure speculation, though. (And don't know re: your question.)
> tends to emphasize compile speed over producing optimal executables So they opted to handle the easy problem.
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.
The infrastructure Google uses to distribute and track builds across datacentres and the world to make compile time of large applications bearable isn't exactly trivial.
Optimal executables aren't that important most of the time. Hardware is cheaper than dev time and the gain of 'optimal' isn't much for the compile time trade off.
Re: Go 1.3 Linker Overhaul
#8Earlier quoted context omitted.
> tends to emphasize compile speed over producing optimal executables So they opted to handle the easy problem.
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. The infrastructure Google uses to distribute and track builds across datacentres and the world to make compile time of large applications bearable isn't exactly trivial. Optimal executables aren't that important most of the time. Hardware is cheaper than de…
>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.
Re: Go 1.3 Linker Overhaul
#9Interestingly, they want to do the opposite of what Microsoft did with their C++ compiler and linker. To enable "whole program optimizations" Microsoft's compiler writers added the intermediate code analysis, optimizations and code generation to the linker, allowing to, for example, if it is beneficial, inline function invocations for small functions that aren't declared as inline and that come from the different mod…
Go's gc toolchain (as opposed to gccgo) tends to emphasize compile speed over producing optimal executables, so they may be flat-out deciding to leave some potential whole-program optimizations on the table to for link speed--pure speculation, though. (And don't know re: your question.)
Now that the modules are mentioned in the discussion: can one Go application consist of more .so or .dlls all writren in Go at all?
Re: Go 1.3 Linker Overhaul
#10Earlier 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. The infrastructure Google uses to distribute and track builds across datacentres and the world to make compile time of large applications bearable isn't exactly trivial. Optimal executables aren't that important most of the time. Hardware is cheaper than de…
> 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) no comment.
2) This is about the linker, not the compiler. You should compare the compilation times with the linking times instead of making assumptions.