Slow performance compared to C++, ideas?

Manu turkeyman at gmail.com
Fri May 31 16:04:50 PDT 2013


On 1 June 2013 02:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

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

**applause**
Someone other than me said it, out loud!
This is a magnificent day! :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130601/98f50a63/attachment.html>


More information about the Digitalmars-d mailing list