Slow performance compared to C++, ideas?

deadalnix deadalnix at gmail.com
Thu May 30 21:06:55 PDT 2013


On Friday, 31 May 2013 at 02:56:25 UTC, Andrei Alexandrescu wrote:
> On 5/30/13 9:26 PM, finalpatch wrote:
>> https://dl.dropboxusercontent.com/u/974356/raytracer.d
>> https://dl.dropboxusercontent.com/u/974356/raytracer.cpp
>
> Manu's gonna love this one: make all methods final.
>

I don't think going as far as making thing final by default make 
sense at this point. But we sure need a way to be able to 
finalize methods. We had an extensive discussion with Don and 
Manu at DConf, here are some idea that came out :

  - Final by default

This one is really a plus when it come to performance code. 
However, virtual by default have proven itself very useful when 
performance isn't that big of a deal (and it is the case for 90% 
of a program's code usually) and limiting the usage of some 
pattern like decorator (that also have been proven to be useful). 
This is also  huge breakage.

  - Introduce a virtual keyword.

Virtual by default isn't such a big deal if you can do final: and 
reverse the default behavior. However, once you key in the final 
land, you are trapped here, you can't get out. Introducing a 
virtual keyword would allow for aggressive final: declarations.

  - Require explicitly export when you want to create shared 
objects.

This one is an enabler for an optimizer to finalize virtual 
method. With this mechanism in place, the compile knows all the 
override and can finalize many calls during LTO. I especially 
like that one as it allow for stripping many symbols at link time 
and allow for other LTO in general (for instance, the compiler 
can choose custom calling conventions for some methods, knowing 
all call sites).

The explicit export one have my preference, however, ti require 
that symbol used in shared lib are explicitly declared export. I 
think we shouldn't break the virtual by default behavior, but we 
still need to figure out a way to make thing more performant on 
this point.


More information about the Digitalmars-d mailing list