Slow performance compared to C++, ideas?

Walter Bright newshound2 at digitalmars.com
Thu Jun 6 16:48:32 PDT 2013


On 6/6/2013 3:12 PM, Jonathan M Davis wrote:
> On Thursday, June 06, 2013 14:57:00 Walter Bright wrote:
>> On 6/6/2013 2:23 PM, Andrei Alexandrescu wrote:
>>> (The tool I'm envisioning
>>> would add final annotations or prompt the user to add them.)
>>
>> Sorry, that's never going to fly.
>
> It could tell the programmer which functions it _thinks_ don't need to be
> virtual, but it can't be 100% correct. So, it would effectively be a lint-like
> tool targeting possible devirtualization opportunities. It would actually be
> potentially useful regardless of whether virtual or non-virtual is the
> default, since programmers may have needlessly marked functions as virtual.
> But if it's a question of whether it's a good solution for optimizing away
> virtuality instead of making functions non-virtual, then I don't think that it
> would fly - not if optimization is a prime concern. It would just be a nice
> helper tool for static analysis which could give you suggestions on things you
> might be able to improve in your program.

I know. But people are never going to use that tool.


> But as it sounds like the primary argument which has swayed you towards making
> non-virtual the default is tied to cleaner code evolution and maintenance
> rather than performance, the suggestion obviously wouldn't be a viable
> counterargument for going with virtual-by-default.

The thing is, when code 'works' there is rarely sufficient motivation to go back 
and annotate things for safety and performance (hence why the tool above will be 
a failure). Code that works is left alone, and we see the situation Manu is 
talking about.

But if it's final by default, if the user needs it to be virtual, then he has to 
go back and add the annotation - it's not going to work, and the compiler will 
tell him it doesn't work.

I wouldn't have changed my mind if it were possible for the compiler to 
auto-finalize methods.

BTW, this is also why D hasn't opted for the pointer tagging system Rust has. It 
all looks great on paper, but I suspect that in practice not much use will be 
made of it - people will just default to using the most widely usable pointer 
type and their code will work and they'll forget about the rest of the annotations.

I have a lot of experience with this with DOS 16 bit code. There we had all 
kinds of pointer types - near, far, SS relative, CS relative, etc. You know what 
people did? The default pointer type. Almost nobody used those optimized pointer 
types, even though they got big speed boosts when used appropriately.

What does work is throw -O and have the compiler go to town and optimize the 
hell out of it. As much as possible we should be selecting default semantics 
that enable -O to kick ass.



More information about the Digitalmars-d mailing list