Slow performance compared to C++, ideas?

[Jonathan M Davis]

On Friday, May 31, 2013 19:42:55 Manu wrote:
> On 31 May 2013 14:06, deadalnix <deadalnix at gmail.com> wrote:
> > 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.drop
> >>> boxusercontent.com/u/974356/raytracer.d>
> >>> https://dl.dropboxusercontent.**com/u/974356/raytracer.cpp<https://dl.d
> >>> ropboxusercontent.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.
> 
> The correct choice :)
> 
> > virtual by default have proven itself very useful when performance isn't
> 
> that big of a deal
> 
> Has it? I'm not sure it's ever proven its self useful, can you point to any
> such proof, or evidence?

It's useful when you don't have override, because you avoid the problem of 
overriding non-virtual functions. So, going with virtual by default solves 
that nasty bug, but enforcing override _also_ solves it. So IMHO, requiring 
override (which we already do) solves the problem, making it pointless to make 
member functions virtual by default. At that point, it just makes more sense 
to make them non-virtual by default and avoid the performance issues caused by 
virtual by default. The _only_ thing that it costs you is that it forces you 
to put virtual on all functions which are going to be overridden, which is 
even fewer functions than we have to mark with override (because multiple 
classes can override whereas only the base class function would be marked with 
virtual).

> There's another detail that came up late at night at dconf; I was talking
> to Daniel Murphy about the extern(C++) class work he's working on to write
> the D-DMD front end, and apparently it would make the problem a lot easier
> if virtual was explicit there too. So perhaps it also offers improved
> interoperability with C++, which I think most of us have agreed is of
> heightened importance recently.

Yes. I intend to create a DIP for non-virtual by default (assuming that no one 
else does first), and I think that this issue gives even more weight to why we 
need to make the change.

> > This is also huge breakage.
> 
> I think this is another fallacy. The magnitude of the breakage is already
> known. It's comparable to the recent change where 'override' became an
> explicit requirement, which was hardly catastrophic.
> In that case, the breakage occurred in *every derived class*, which is a
> many:1 relationship to base classes.
> Explicit virtual would only affect _base_ classes. The magnitude of which
> is far smaller than what was recently considered acceptable, precisely:
> magnitudeOfPriorBreakage / numberOfDerivedClasses.
> 
> So considering explicit override was an argument won, I'd like to think
> that explicit virtual deserves the same treatment for even more compelling
> reasons, and at a significantly lesser cost in breakage.

Yes. The breakage is surprisingly small, and the change is arguably critical 
for both performance-critical code and for moving the compiler frontend to D.

- Jonathan M Davis