Slow performance compared to C++, ideas?

[Manu]

On 8 June 2013 01:23, deadalnix <deadalnix at gmail.com> wrote:

> Requiring classes to be exported provide the following benefit :
>  - LTO can finalize methods that aren't overridden. It include function
> that you want virtual by design, but you don't use that capability is your
> specific situation. In this regard, this is superior to the explicit
> virtual solution as it do not require to annotate virtual and can finalize
> method that would have to be annotated virtual.
>  - Shared object can be stripped of all non exported symbols, reducing
> their size.
>  - Reduce the surface area of breakage for shared objects.
>
> It however require careful crafting of exported objects. I think this is
> mitigated by the fact that shared object interface require careful crafting
> anyway, as what is exported cannot be unexported (and cannot even change
> its ABI in way that aren't easily visible in the source).
>
> The solution can be completed later by a tool as Andrei proposed (great
> idea), but by itself provide a lot of opportunity to finalize
> automagically. As you argued, this is the best way to go.
>
> Executive summary :
>  - We can provide a toll to finalize the whole program.
>  - We can automatically finalize everything that isn't exported.
>  - We don't break any code.
>  - We get consistency between windows and UNIXes.
>  - Manu will rant.
>
> I see only benefits :D
>

It's like you've missed most of my points though.

So under this proposal, which *entails* said 'sufficiently advanced
optimiser/linker/etc', which doesn't exist. And even if it did, what
architectures are supported?
Many architectures will most certainly never receive support, and these are
usually the architectures that need it most.

Put that aside for a second, it's still flawed in a basic sense.

Anything 'exported' still falls under precisely the same set of problems as
we have now. By exporting something, NOTHING can be de-virtualised, even
when used internally. And exported things DO get used internally. So by
exporting, you lose all benefit within your own code anyway.
I can tell you that in my case, we export a lot(/most) things. Renderer
api, sound api, etc are often all in their own libraries. So none of them
are ever eligible for optimisation.

Additionally, one of my central points is completely un-satisfied, that is,
3rd party libraries. To make use of them at all implies they are exported,
so there is never any possibility for optimisation there.

What am I left with? Basically nothing.

And finally, even if none of these problems existed, you still don't want
virtual methods across export boundaries.
Just because you use a class implemented in a DLL, that doesn't prevent you
from inlining the trivial accessors within your own code. Using a library
is an ABI commitment anyway, and it's completely normal to inline foreign
libraries trivial methods within your own code.

So, basically none of my usages are satisfied by your proposal.
Sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130608/ba2a38c6/attachment.html>