One document about Go

[Walter Bright]

bearophile wrote:
> Walter Bright:
> 
>> Firstly, this is not a back end vs front end issue. A compiler can do it in
>> 
> either place, neither is inherently better than the other.<
> 
> You are right. This thread has gone in wrong directions. What I meant was:
> Scala language is designed to use delegates often. For example the map maps a
> delegate on a collection, it never uses a string as Phobos2 map(). Scala
> compiler keeps its language efficent, despite all those delegates, because it
> contains a "large" amount of logic (separated from the large amount of
> optimization logic in the JavaVM itself) that allows it to often inline those
> delegates. LLVM developers have started to work on this problem too, and
> maybe eventually LLVM too (so LDC too) will enjoy some of such optimizations.
> The end result is that if you map a delegate on a Scala collection, it often
> gets inlined and this improves performance, while D LDC currently doesn't.

dmd inlines delegates to templates when they are passed as alias parameters.



>> Secondly, in what way does LLVM give better inline results?<
> 
> I am not a LLVM/LDC designer, and in the end I am pretty ignorant about
> compiler still. Until few days ago DMD didn't inline functions with ref
> arguments, while the inliner of llvm didn't have this limit, so this is place
> where LLVM was better. I'd like to give you more examples or a more detailed
> explanation, but I can't (maybe in D bugzilla there are more examples where
> the inliner fails, I don't know). Maybe LDC developers can give you a better
> answer. I find it funny that LDC devs seem to never talk about LDC here, I am
> not expert enough to talk about LDC, yet it seems no one else that knows more
> than me is talking about it here :-)

I know you're a fan of LLVM, but it would be fair to provide examples when 
saying things like LLVM does a better job on X. I would agree that LLVM does a 
far better job of marketing.

For example, many years ago, Microsoft came out with "incremental linking" as a 
cool new feature to speed up the link process. This got a lot of buzz in the 
press. My manager at the time decided we need an "incremental linking" feature 
in order to catch up to Microsoft. A big all-hands meeting ensued. The thing is, 
"incremental linking" was a hack that was necessary to work around a very slow 
linker. Our linker (optlink) was so fast that it ran rings around "incremental 
linking" even while always doing a full link. We'd failed to get this message 
out, even to our own management.