Slow performance compared to C++, ideas?

[deadalnix]

On Friday, 7 June 2013 at 07:31:52 UTC, Walter Bright wrote:
> deadalnix mentioned enforcing 'export' on classes exposed to 
> shared libraries, but then aren't we back to expecting user 
> annotation rather than doing things automatically?

Yes, let me explain more.

The export problem isn't new, and you'll find 2 major approach : 
the UNIX approach of export everything, and the windows approach 
of requiring explicit export.

The first approach tend to show its limit. It limit what the 
optimizer can do, and create binary more and more costly to link 
(especially since the number of symbol tends to explode with 
metaprogramming) (linking a debug version of LLVM as shared 
object for instance is quite costly).

Both GCC and clang propose language extensions to manage export 
explicitly on UNIXes.

Additionally, it is beneficial to be very picky about what is 
exported. Once something is exported, you are tied to an API (as 
with public) but also to an ABI. Adding a function to a class for 
instance, can cause a relayout of the vtable. None of the 
existing interface is broken, but the shared object is broken 
anyway, because of symbols it don't use.

Considering this, we need either a way to export explicitly, or 
the other way around. It is also worth noting that consistency 
accross plateforms is a plus, and this is an area where we can do 
better that C (and we already do).

Regarding virtual in particular, it is known that calling a 
virtual method have a cost. It cause an indirect branch, but also 
prevent the compiler from optimizing, as the call is opaque. The 
same way, calling to a shared object is opaque to the compiler, 
and so, you can't get the full benefice of finalizing the 
exported function.

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