Slow performance compared to C++, ideas?

Simen Kjaeraas simen.kjaras at gmail.com
Tue Jun 4 05:27:34 PDT 2013


On 2013-06-04, 13:15, Manu wrote:

> I'll summarise my arguments, though I've done this at least 3 times now.
> Sorry, I 'value' more of my points than you, so my summary is quite  
> longer.
> These are all supporting reasons why I think it would be a good change,  
> and
> naturally, some are of lower significance then than others.
> I'd like to think that most of them should be objectively rejected, or  
> the
> counter arguments list grows in size a whole lot to justify the insults  
> you
> offer:
>
> * At top level I believe D aspires to be a systems language, and
> performance should certainly be a key concern.
>   - 'Flexibility' [at the expense of performance] should be opt-in. It
> comes at the expense of what I presume should be a core audience for a
> systems language.
>   - x86 is the most tolerant architecture _by far_, and we're committed  
> to
> a cost that isn't even known yet on the vast majority of computers in the
> world.
>
> * virtual is a one-way trip. It can't be undone without risking breaking
> code once released to the wild. How can that state be a sensible default?
>   - Can not be un-done by the compiler/linker like it can in other
> (dynamic) languages. No sufficiently smart compiler can ever address this
> problem as an optimisation.
>
> * The result of said performance concern has a cost in time and money for
> at least one of D's core audiences (realtime systems programming).
>   - I don't believe the converse case, final-by-default, would present  
> any
> comparative loss for users that want to write 'virtual:' at the top of
> their class.
>   - 'Opportunistic de-virtualisation' is a time consuming and tedious
> process, and tends to come up only during crunch times.
>
> * "Classes routinely should make most methods final because it's hard to
> imagine why one would override [the intended] few. Since those are a
> minority, it's so much the better to make final the default."
>   - The majority of classes are leaf's, and there's no reason for leaf
> methods to be virtual by default. Likewise, most methods are trivial
> accessors (the most costly) which have no business being virtual either.
>   - It's also self-documenting. It makes it clear to a customer how the  
> API
> is to be used.
>
> * Libraries written in D should hope to be made available to the widest
> audience possible.
>   - Library author's certainly don't consider (or care about) everyone's
> usage cases, but they often write useful code that many people want to  
> make
> use of. This is the definition of a library.
>   - They are almost certainly not going to annotate their classes with  
> lots
> of 'final'.
>   - Given hard experience, when asked to revoke virtual, even if authors
> agree in principle, they will refuse to do it given the risk of breakage
> for unknown customers.
>   - Adding final as an optimisation is almost always done post-release,  
> so
> it will almost always run the risk of breaking someones code somewhere.
>
> * Experience has shown that programmers from C++/C# don't annotate  
> 'final'
> even when they know they should. Users from Java don't do it either, but
> mainly because they don't consider it important.
>   - Note: 'the most performance conscious users' that you refer to are
> often not the ones writing the code. Programmers work in teams, sometimes
> those teams are large, and many programmers are inexperienced.
>
> * final-by-default promotes awareness of virtual-ness, and it's  
> associated
> costs.
>   - If it's hidden, it will soon be forgotten or dismissed as a trivial
> detail. It's not... at least, not in a systems language that attracts
> high-frequency programmers.
>
> * 'Flexibility' may actually be a fallacy anyway. I personally like the
> idea of requiring an explicit change to 'virtual' in the base when a new
> and untested usage pattern is to be exploited, it gives me confidence.
>   - People are usually pretty permissive when marking functions virtual  
> in
> C++, and people like to consider many possibilities.
>     - When was the last time you wanted to override a function in C++,  
> but
> the author didn't mark it virtual? Is there actually a reduction in
> flexibility in practise? Is this actually a frequent reality?
>   - Overriding unintended functions may lead to dangerous behaviours  
> never
> considered by the author in the first place.
>     - How can I be confident in an API when I know the author couldn't  
> have
> possibly tested all obscure possibilities available. And how can I know  
> the
> extent of his consideration of usage scenarios when authoring the class?
>       - At best, my obscure use case has never been tested.
>     - 'virtual is self-documenting, succinctly communicating the authors
> design/intent.
>
> * Bonus: Improve interoperability with C++, which I will certainly
> appreciate, but this point manifested from the D-DFE guys at dconf.
>
>
> And I'll summarise my perception of the counter arguments argument:
>
> * It's a breaking change.
>
> * 'Flexibility'; someone somewhere might want to make use of a class in a
> creative way that wasn't intended or tested. They shouldn't be prohibited
> from this practise _by default_, in principle.
>   - They would have to contact the author to request a method be made
> virtual in the unlikely event that source isn't available, and they want  
> to
> use it in some obscure fashion that the author never considered.
>     - Note: This point exists on both sides, but on this side, the author
> is likely to be accommodating to their requests.
>   - Authors would have to write 'virtual:' if they want to offer this  
> style
> of fully extensible class.


For whatever it's worth, I have the same impression as you - virtual-by-
default is one-way and unsafe, and its benefits seem questionable.

I admit at first I thought it was a good idea - "great, the compiler'll
figure it out for me!". But that's not the case, so I was forced to revise
my opinion.

-- 
Simen


More information about the Digitalmars-d mailing list