Faster Virtual Method Dispatch

[Craig Black]

"Sean Kelly" <sean at f4.ca> wrote in message 
news:e2lpjj$hvv$1 at digitaldaemon.com...
> In article <e2lhhq$6qv$1 at digitaldaemon.com>, Craig Black says...
>>
>>
>>"Sean Kelly" <sean at f4.ca> wrote in message
>>news:e2lgsh$5tf$1 at digitaldaemon.com...
>>> Craig Black wrote:
>>>>
>>>> If you think this is doable, then you should write a C++ version of
>>>> wordcount based on this principal.  If you can get comparable 
>>>> performance
>>>> to the D version then you may be on to something.
>>>
>>> I'd meant to do this and never got around to it.  However, the wordcount
>>> example is meant to compare performance using typical programming
>>> techniques for each language, and writing your own specialized 
>>> containers
>>> isn't typical :-)
>>
>>That's not the point.  It demonstrates that the same performance can be
>>achieved without GC, and all the baggage that accompanies it.  So
>>performance-wise it would be like having your cake and eating it too.  If
>>this was possible, perhaps D could be streamlined to take advantage of 
>>this
>>somehow.
>
> I merely meant that that's not the point of the wordcount example. 
> However,
> I'll try and find the time to recode it using slices and hashtables in the 
> next
> few days.  IIRC that brings performance in line with the D version, so I 
> suppose
> that means you can "have your cake and eat it too."  It's worth 
> mentioning,

Great!  I look forward to seeing the results.

> however, that slicing with explicit memory management doesn't have quite 
> the
> utility it does with garbage collection.  It works great for apps where 
> the
> entire buffer can be loaded en masse, as with the wordcount example, but 
> in
> other cases it's a bit more complicated to manage the lifetime of the 
> referenced
> data.  Thus the GC version is still a clear win in terms of ease of use, 
> whether
> or not performance can be matched with specialized code elsewhere.

Different programmers have different problems that require different 
solutions.  I doubt that we will ever find one approach to make everyone 
happy about everything.  That's why I think GC should be completely 
optional.  Ideally, turning of GC could be as easy as specifying a compiler 
switch.

But maybe I'm wrong.  Maybe GC can be faster than manual memory management, 
but I doubt it.  Either way, we need to optimize this bottleneck somehow.

Although D currenty delivers competitive performance, and is in some ways is 
faster than C++, I still believe we have a few more steps to take before we 
can say with confidence that D provides performance superior to C++.

IMO, the fastest way to get extreme performance from D is (1) make GC 
optional and (2) provide a safe, easy way to take advantage of concurrency 
on multi-core systems.

(There is already work being done on #2 for C++, so we should try to beat 
them to the punch, and provide a superior solution for D.)

This would make D very attractive for performance-demanding applications.  I 
am especially thinking of the game industry, with which I am indirectly 
involved.  This is the kind of stuff that they are very concerned about.  If 
we do not provide a solution to these issues, I fear it will be a big 
deterrent for many, especially since migrating large projects to D from C++ 
requires a large investment.

-Craig