July 31, 2014
On Thursday, 31 July 2014 at 07:07:27 UTC, Jonathan Marler wrote:
> No matter how much you optimize your D code, you will only ever be able to use a subset of what assembly can do.

Such micro-optimizations give only marginal contribution to performance, which is mostly determined by choice of algorithms. The approach to write everything in assembly with manual optimizations is obsolete for many years, at least for desktop platforms. This is also one of the reasons, why optlink is translated to C.

> I would like to see a linker written in D and see how it compares to optlink.  But I would reserve making a decision on moving to another linker until I got some solid performance data.  Some performance data for a D linker compiled with all three D compilers as well.

I only wanted to say, no matter what performance data we get, the linker can be optimized by choosing faster algorithms without tinkering with assembler.
July 31, 2014
"Jonathan Marler"  wrote in message news:xrpdzjuaxtdhyfhpsgcu@forum.dlang.org...

> I like the discussion.  I do want to remind everyone that OPTLINK is very fast and switching to a different linker will likely result performance hit.  There are advantages to using COFF as it seems more compilers use that format and D would be more interoperable with other compilers and languages.  I think every peice of software has it's own goals which determine what tradeoffs to chose.  In my view, the linker should 1) always work and 2) be as fast as possible.  OPTLINK passes number 2 with flying colors but is does have bugs.  This is obviously due to the fact that it is written in assembly but keep in mind that the performance of the linker affects everyone who uses D.  Any performance hit on the linker will be seen in every single build of any D program. Adding 1 second to link time will add 1 second to build time since this process cannot be parallelized (as far as I know).

Optlink simply doesn't do enough.  It doesn't support modern debug info formats.  It doesn't support mixing omf and coff object files (this is probably the most requested feature, because it would allow using the stock import libraries).

Worst of all, optlink is hostile to change.

win32 is dying, and optlink will certainly die with it.  Having a more accessible linker will let us adapt much faster. 

August 06, 2014
On 2014-07-30 14:51, w0rp wrote:

> I think it's important to ship with a linker without requiring any
> further installation.

Just for the record. Currently, Windows in the only platform where this is true.

-- 
/Jacob Carlborg
1 2 3
Next ›   Last »