<div dir="ltr">On 7 June 2013 10:44, deadalnix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Thursday, 6 June 2013 at 23:54:49 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

The trouble, as has been pointed out before, is shared libraries.<br>
<br>
</blockquote>
<br>
And the existence of 'sufficiently smart linker', and the fact that the<br>
platforms that suffer from this stuff way harder than x86 almost always<br>
have less mature compilers/optimisers/linkers.<br>
I just wouldn't ever place my faith in the future arrival of some<br>
sufficiently-smart-[tool]. You couldn't make a business investment on that<br>
illusive possibility.<br>
</blockquote>
<br>
GCC and LLVM have what it take to implement this kind of stuff<br>
and can do codegen for a large variety of plateforms. I think<br>
it's never gonna work with dmd, and I think this is why Walter<br>
and yourself are pushing that hard to break everybody's code.<br>
</blockquote></div><br></div><div class="gmail_extra" style>IIRC, GCC requires explicit support for LTO in the backend, which means minority architectures will probably never get support, and these are the ones that need it the most.</div>
<div class="gmail_extra" style>Don't know about LLVM, but I'll bet again, the minority architectures will not have good support.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>And there's still the DLL case.</div>
<div class="gmail_extra" style>You can't simply compare the relative cost of a DLL call and a virtual call (although a DLL call is still slightly less work than a virtual call).</div><div class="gmail_extra" style>The real issue is though, that code within your program which IS subject to LTO still can't have a de-virtualisation optimisation applied anyway, since it can't know if a DLL might introduce a new derived class.</div>
<div class="gmail_extra" style><div class="gmail_extra" style>The possibility of a DLL simply existing means such an optimisation can't be performed, even if it is possible.</div><div class="gmail_extra"><br></div></div>
<div class="gmail_extra" style>If D were a JITed language, I wouldn't make a fuss. But it's not, it's a compiled systems language, and it's the only realistic competitor to C++ I know of in the same space.</div>
<div class="gmail_extra" style>All other JIT languages have alternatives, they live in a crowded space, and while D might be a compelling option in those spaces, in the compiled systems space, D pretty much stands alone, and would do well not to inhibit the needs of those users.</div>
</div>