Benchmark of D against other languages

[Daniel Kozák via Digitalmars-d]

On Thu, 02 Apr 2015 11:00:12 +0000
lobo via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Thursday, 2 April 2015 at 09:06:52 UTC, Manu wrote:
> > On 2 April 2015 at 08:15, Martin Nowak via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >> On 04/01/2015 10:31 PM, novice2 wrote:
> >>> Can DMD compiler do it itself, as one of optimizations?
> >>
> >> You could do it as part of LTO or whole program optimization.
> >> It requires another compiler/linker phase, so it's not easy to 
> >> achieve,
> >> maybe the LDC/GDC people have LTO running?
> >>
> >> GCC5 comes with a big announcement about devirtualization.
> >> https://www.gnu.org/software/gcc/gcc-5/changes.html#general
> >
> > It is impossible to do a good job. There are 2 conditions that 
> > break
> > most opportunities that the compiler may have to improve this:
> > 1) The class is a pointer (duh, in D, all classes are pointers, 
> > so
> > that condition is implicit).
> > 2) That DLL's exist.
> >
> > If a DLL may exist, and a class is a pointer (it is), sourced 
> > from an
> > 'impure' location, then it is impossible for the compiler to 
> > generally
> > do anything at all about final.
> > It may theoretically be able to do something in the case where 
> > the
> > class is proofably contained within a 'scope' confined 
> > space/function,
> > but that particular case is almost mutually exclusive with 
> > cases where
> > polymorphism is actually useful in the first place, so it's not 
> > really
> > practical. I also imagine the complexity in the compiler would 
> > be off
> > the charts.
> >
> > Basically, if it is _possible_ for a class pointer to come in 
> > contact
> > with dynamically loaded code, the compiler must conservatively 
> > abandon
> > any attempt to optimise.
> >
> > virtual by default is completely wrong for D.
> >
> > And don't say 'speculative' devirtualisation. What an 
> > abomination!
> > Just fix the problem; don't have every function be virtual in 
> > the
> > first place!
> 
> +1
> 
> Even an escape would be useful so one can do this:
> 
> final class Hack {
>      virtual void func() {}
> }
> 
> It would then be trivial to stick a final in front of the class.
> 
> It would also be required to declare final when instantiating the 
> class, to work with third-party libraries that don't use final, 
> i.e.
> 
> auto klass = new final Class();
> 
> 
> I'm not a language developer and I don't know D that well yet so 
> I'll stop there before I embarrass myself too much! :D
> 
> bye,
> lobo
> 

final class Hack {
    virtual void func() {}
}

I do not see how this would help?

If you make class Hack final, you can not use inheritence anymore so
having virtual void func() does not make sense to me.

class Hack {
final:
    // some final methods
    virtual void func() {}
}

makes more sense ;)