On Saturday, 21 September 2013 at 10:53:17 UTC, Peter Alexander wrote:
> On Saturday, 21 September 2013 at 10:29:35 UTC, Dicebot wrote:
>> Lot of code bloat comes from stuff which is unnecessary in the big picture but compiler has to means to decide it during compilation. There is no real reason why
>>
>> `[1, 2, 3].map!(a => a*2)().reduce!((a, b) => a + b)(0)`
>>
>> can't be reduce to single loop and inlined, leaving no traces of actual std.algorithm usage.
>
> There's no theoretical reason, but plenty of practical reasons. bearophile linked to a talk by Chandler Carruth that explains the difficulties encountered by inlining optimisers.

I wasn't referring to actual inlining but to "remove all unused that is left after inlining". You point is solid, of course, there is nothing trivial about robust inline optimizations - but is possible within existing language design.

On Saturday, 21 September 2013 at 10:53:17 UTC, Peter Alexander wrote:
> On Saturday, 21 September 2013 at 10:29:35 UTC, Dicebot wrote:
>> Lot of code bloat comes from stuff which is unnecessary in the big picture but compiler has to means to decide it during compilation. There is no real reason why
>>
>> `[1, 2, 3].map!(a => a*2)().reduce!((a, b) => a + b)(0)`
>>
>> can't be reduce to single loop and inlined, leaving no traces of actual std.algorithm usage.
>
> There's no theoretical reason, but plenty of practical reasons. bearophile linked to a talk by Chandler Carruth that explains the difficulties encountered by inlining optimisers.

Either you are confusing with me ( http://forum.dlang.org/thread/mvbqiwajntrivndylelw@forum.dlang.org?page=8#post-mqcwjbgxildixehsxthe:40forum.dlang.org ) or I missed that post by bearophile.

Also, Dicebot have some very good points. Function can't be stripped from the executable if they are exported by default.

It's executable, not a DLL. So any functions can be stripped.
Isn't it ?

On Saturday, 21 September 2013 at 11:17:46 UTC, Temtaime wrote:
> It's executable, not a DLL. So any functions can be stripped.
> Isn't it ?

Not any. You must preserve those symbols that are exposed to DLL via callbacks or parameter types (functions are not only symbols that bloat). Now, it may be possible to compiler to detect those automatically  as passing parameter implies manual reference from code but I am not sure about that (D never stops to surprise me about weird hacks it can do :P)

Are you saying about passing a function via pointer to winapi for example?
The logic is simple: if someone gets function address, then function cannot be stripped. It's logic of all c++ compilers.

On Saturday, 21 September 2013 at 11:34:10 UTC, Temtaime wrote:
> Are you saying about passing a function via pointer to winapi for example?
> The logic is simple: if someone gets function address, then function cannot be stripped. It's logic of all c++ compilers.

More like passing an object instance to plugin which knows it only via .di import. Compiler can't possibly know what methods of that object (or function indirectly   accessible from it) will be available in the .di and/or called and must act conservatively, preserving everything.

It will also need to be aware of fact that function pointer retrieved via `dlsym` is actually some external function and use that knowledge during optimization.

Also it is worth noting that naive preservation of all functions that got their address may not work very well with frequent lambda usage for algorithms in D.

Same stuff with inheritance. It is just another side of a problem why compiler can't de-virtualize certain methods based on whole program class graph.

I won't be as harsh as to say it is impossible but this clearly requires defining some parts of the language that are currently vague.

P.S. C++ compilers are not much better here in that regard, unless you are going to try some non-standard tweaks.

On Saturday, 21 September 2013 at 11:46:13 UTC, Dicebot wrote:
> ...

P.S. A lot of those problems can be avoided even without Whole Program Optimization if internal linkage attribute is introduced ;)

On Saturday, 21 September 2013 at 11:11:09 UTC, deadalnix wrote:
> On Saturday, 21 September 2013 at 10:53:17 UTC, Peter Alexander
>> There's no theoretical reason, but plenty of practical reasons. bearophile linked to a talk by Chandler Carruth that explains the difficulties encountered by inlining optimisers.
>
> Either you are confusing with me ( http://forum.dlang.org/thread/mvbqiwajntrivndylelw@forum.dlang.org?page=8#post-mqcwjbgxildixehsxthe:40forum.dlang.org ) or I missed that post by bearophile.

Sorry, I am just confused :-)

On 21 September 2013 21:34, Temtaime <temtaime@gmail.com> wrote:

> Are you saying about passing a function via pointer to winapi for example? The logic is simple: if someone gets function address, then function cannot be stripped. It's logic of all c++ compilers.
>

Totally OT, but every single time I read your name when you post, I can't help but start hearing lines from Terry Prachett's Hogfather in my head... http://www.youtube.com/watch?v=M0mU3393PGk

Although I suspect not many people would have seen it.
My brain is a strange place...

On Friday, 20 September 2013 at 16:20:34 UTC, Duke Normandin wrote:
> I'm re-visiting the D language. I've compared the file sizes of 2 executables - 1 is compiled C code using gcc; the other is D code using dmd.
>
> helloWorld.d => helloWorld.exe = 146,972 bytes
> ex1hello.c => ex1-hello.exe = 5,661 bytes
>
> Why such a huge difference???

You can upload a .map file here, and see what's taking up all the space:
http://thecybershadow.net/d/mapview/