On 6/6/2013 5:44 PM, deadalnix wrote:
> GCC and LLVM have what it take to implement this kind of stuff
> and can do codegen for a large variety of plateforms. I think
> it's never gonna work with dmd, and I think this is why Walter
> and yourself are pushing that hard to break everybody's code.

Please explain how they deal with the shared library issue.

On 6/6/2013 5:43 PM, Jakob Ovrum wrote:
> On Friday, 7 June 2013 at 00:34:45 UTC, deadalnix wrote:
>> Yes, which happen anyway for shared objects !
>
> This.
>
> We can do whole-program-optimization to finalize
> non-shared-library functions - and for shared-library functions
> it doesn't make sense to finalize for performance - you're
> trading one kind of indirection function call for another.
>
> Can we all please address or recognize this?

Sure, but the trouble is determining which classes are going to be shared.

On Friday, 7 June 2013 at 01:12:07 UTC, Walter Bright wrote:
> On 6/6/2013 4:56 PM, Flamaros wrote:
>> I think it depend of his simplicity and integration in the common D process
>> development. Maybe because D build fast we can add some extra steps during build
>> of the release?
>> And developers of companies that develop the biggest application will be aware
>> of this tool and certainly have script or advanced tools to build their software
>> release, adding a line during the building process seems acceptable.
>
> Consider a trivial and effective DMD tool for debugging and improving efficiency:
>
>    -cov
>
> and I'm the only one I know of that uses it.
>

Integration to IDE is the key. I did use similar tool in many
languages but only rarely in D.

On Friday, 7 June 2013 at 01:22:25 UTC, Walter Bright wrote:
> On 6/6/2013 5:43 PM, Jakob Ovrum wrote:
>> On Friday, 7 June 2013 at 00:34:45 UTC, deadalnix wrote:
>>> Yes, which happen anyway for shared objects !
>>
>> This.
>>
>> We can do whole-program-optimization to finalize
>> non-shared-library functions - and for shared-library functions
>> it doesn't make sense to finalize for performance - you're
>> trading one kind of indirection function call for another.
>>
>> Can we all please address or recognize this?
>
> Sure, but the trouble is determining which classes are going to be shared.

By requiring export for what can be shared. Can be enforced by
setting the visibility of the class's typeid.

On 7 June 2013 10:44, deadalnix <deadalnix@gmail.com> wrote:

> On Thursday, 6 June 2013 at 23:54:49 UTC, Manu wrote:
>
>> The trouble, as has been pointed out before, is shared libraries.
>>>
>>>
>> And the existence of 'sufficiently smart linker', and the fact that the
>> platforms that suffer from this stuff way harder than x86 almost always
>> have less mature compilers/optimisers/linkers.
>> I just wouldn't ever place my faith in the future arrival of some
>> sufficiently-smart-[tool]. You couldn't make a business investment on that
>> illusive possibility.
>>
>
> GCC and LLVM have what it take to implement this kind of stuff and can do codegen for a large variety of plateforms. I think it's never gonna work with dmd, and I think this is why Walter and yourself are pushing that hard to break everybody's code.
>

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.
Don't know about LLVM, but I'll bet again, the minority architectures will
not have good support.

And there's still the DLL case.
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).
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.
The possibility of a DLL simply existing means such an optimisation can't
be performed, even if it is possible.

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.
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.

On 7 June 2013 11:27, deadalnix <deadalnix@gmail.com> wrote:

> On Friday, 7 June 2013 at 01:22:25 UTC, Walter Bright wrote:
>
>> On 6/6/2013 5:43 PM, Jakob Ovrum wrote:
>>
>>> On Friday, 7 June 2013 at 00:34:45 UTC, deadalnix wrote:
>>>
>>>> Yes, which happen anyway for shared objects !
>>>>
>>>
>>> This.
>>>
>>> We can do whole-program-optimization to finalize non-shared-library functions - and for shared-library functions it doesn't make sense to finalize for performance - you're trading one kind of indirection function call for another.
>>>
>>> Can we all please address or recognize this?
>>>
>>
>> Sure, but the trouble is determining which classes are going to be shared.
>>
>
> By requiring export for what can be shared. Can be enforced by setting the visibility of the class's typeid.
>

But you realise that a shared library isn't EXCLUSIVELY shared, it is still
used internally?
And the act of sharing it under your proposal means it can't be optimised
ANYWHERE, even for internal usage.

On Friday, 7 June 2013 at 01:32:17 UTC, Manu wrote:
> 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.
> Don't know about LLVM, but I'll bet again, the minority architectures will
> not have good support.
>

LTO is done y dumping the IR in the object file. The codegen
occurs after LTO if they are enabled.

> And there's still the DLL case.
> 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).

The only difference is the indirect branch. In both cases the
compiler is blind, so it will be slow. You are right, the
indirect branch is an additional cost.

In the case of a static call, you can expect the call to be
several time faster, when you'll only get a marginal improvement
on shared object.

> 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.
> The possibility of a DLL simply existing means such an optimisation can't
> be performed, even if it is possible.
>

This is why I'm proposing for the nth time that virtual is
enforced by the compiler. And yes, this can be done by setting
the visibility of class's typeid (so overriding a class that
isn't exported is a link time error).

On Friday, 7 June 2013 at 01:12:07 UTC, Walter Bright wrote:
> and I'm the only one I know of that uses it.

I've used it in LuaD since a couple of years ago to check what
code isn't covered by tests. It's much more useful now that it
has VisualD integration and the -cov=nn form, though.

On 6/6/2013 7:01 PM, Jakob Ovrum wrote:
> On Friday, 7 June 2013 at 01:12:07 UTC, Walter Bright wrote:
>> and I'm the only one I know of that uses it.
>
> I've used it in LuaD since a couple of years ago to check what
> code isn't covered by tests. It's much more useful now that it
> has VisualD integration and the -cov=nn form, though.

There's 2! :-)

On 6/6/2013 6:45 PM, deadalnix wrote:
> This is why I'm proposing for the nth time that virtual is
> enforced by the compiler. And yes, this can be done by setting
> the visibility of class's typeid (so overriding a class that
> isn't exported is a link time error).

The horse may be out of the barn on that one.

People just want to throw a switch and put their code in a DLL (like in libphobos2.so).