Slow performance compared to C++, ideas?

[deadalnix]

On Saturday, 8 June 2013 at 00:16:05 UTC, Manu wrote:
> 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.
>

It seems that you missed some of my points. LTO work by dumping 
the IR in object file. Linker with LTO enabled will read the ir, 
and redo the codegen. So the LTO is done before the codegen, and 
it shouldn't be a problem for most architectures.

I also recognize that architectures are not equal on that regard. 
My reasoning here is that ARM and X86 are roughly 90% of the CPU 
you'll find and they handle indirect branch nicely.

It is a bigger issue for other architectures, but it is desirable 
that architecture that are less used don't clutter the language.

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

My point is that exported symbol require very careful crafting 
anyway. So caring about what is final or not is a concern.

Additionally, it is possible to use th following pattern :
export class Exported {
}

// All intern subclass inherit that one.
class NotExported : Exported {
}

And manipulated the NotExported class internally whenever it is 
possible. It allow for very precise crafting of the exported API, 
which is also a benefit.

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

That is true. However, this would result in an opaque call 
anyway, so opportunity for optimization isn't that big. If this 
is a huge problem, the final keyword is here.

> So, basically none of my usages are satisfied by your proposal.
> Sorry.

I said that you would rant, that one is quite nicela satisfied.