On 4/10/2013 4:00 AM, Manu wrote:
> It doesn't have all sources. It could load a library. That can never be guaranteed.

Currently, a virtual call is done with:

   (*vtbl[i])(args...)

It makes me wonder if the following would be faster:

   method_fp = vtbl[i];
   if (method_fp == &method)
       method(args...)
   else
       (*method_fp)(args...)

Anyone care to dummy this up and run a benchmark?

It's also possible to, for the per-class static data, have a flag that says "isfinal", which is set to false at runtime whenever a new is done for a derived class. Then, the method test above becomes:

    if (isfinal)

Walter Bright:

> On 4/10/2013 4:00 AM, Manu wrote:
>> It doesn't have all sources. It could load a library. That can never be guaranteed.
>
> Currently, a virtual call is done with:
>
>    (*vtbl[i])(args...)
>
> It makes me wonder if the following would be faster:
>
>    method_fp = vtbl[i];
>    if (method_fp == &method)
>        method(args...)
>    else
>        (*method_fp)(args...)
>
> Anyone care to dummy this up and run a benchmark?

It's important to repeat experiments, but I think it's also interesting to take a look at the very extensive amount of experiments already done on such matters since Self virtual machines. The relevant part of the source code of open source JavaVM is worth looking at.

http://en.wikipedia.org/wiki/Inline_caching

http://www.azulsystems.com/blog/cliff/2010-04-08-inline-caches-and-call-site-optimization

http://extras.springer.com/2000/978-3-540-67660-7/papers/1628/16280258.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.3108&rep=rep1&type=pdf

The benchmarking should be done with a both few different little synthetic programs, and one largish program that used virtual calls a lot.

Bye,
bearophile

On 4/8/2013 5:06 AM, Jacob Carlborg wrote:
> I don't know. The thread safe example probably works better with an annotated
> type than nogc.

@nogc would have to be enforced by the compiler. Furthermore, it's viral in that much of the runtime library would have to be gone through and marked @nogc, otherwise it would be fairly useless.

It's a fairly intrusive change.

On 11 April 2013 06:35, Jeff Nowakowski <jeff@dilacero.org> wrote:

> On 04/10/2013 01:14 PM, Nick Sabalausky wrote:
>
>>
>> Well yea, Quantic Dream goes WAAAAAY off into the "interactive movie" realm.
>>
>
> Because that's what the game is. There's nothing wrong with it if you like it, and many people do.


My girlfriend played through Heavy Rain recently, and really liked it.

 Keep in mind, I'm using "interactive movie" largely for lack of a
>> better term. "Videogame" definitely isn't the right word for them.
>>
>
> They're games, and they use the video medium. Video games. The rest of your post is mostly just a rant about what you personally like in video games/"interactive movies". You are of course entitled to an opinion, but the grumpy old man ranting gets old.
>

It's possible they're closer to the traditional term 'video game' than most that came before ;) .. We finally got there!

On 11 April 2013 06:50, Rob T <alanb@ucora.com> wrote:

> On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
>
>> Can you demonstrate a high level class, ie, not a primitive tool, but the
>> sort of thing a programmer would write in their daily work where all/most
>> functions would be virtual?
>> I can paste almost any class I've ever written, there is usually 2-4
>> virtuals, among 20-30 functions.
>>
>>
> In my case it was a C++ virtual class used to supply a common interface to various database libraries. This is not a usual thing, so your point is valid, and I'll agree that most often your classes will have proportionally far less virtual functions overall. It's mostly the base classes that will contain the most virtual functions, but derived classes generally outnumber them.
>
>
>>> Mark your properties as final?
>>>
>>>
>> That's 90% of the class! You are familiar with OOP right? :) Almost everything is an accessor...
>>
>
> Based on what I've learned from this thread, to get the best performance I'll have to wrap up almost all my D classes with "final", or take the more painful alternative route and move all non virtual functions into UFCS.
>
> I can understand the argument in favor if UFCS as the "final" solution, however it's something I'd have to try out first before making a conclusion. Off hand it seem like more work (an example with static if's was shown already), and for code structuring and readability it seems to me it won't be helpful. Again these are my first impressions without actually trying it out, so who knows, it may work well despite my concerns.
>
>
>> Correct, it's not quite a systems language while the GC does whatever it wants. But D needs the GC to be considered a 'modern', and generally productive language.
>>
>
> The GC issue is a recurring one (how many threads on this topic?) because the current implementation directly interferes with the stated goals of D being a systems language.
>
> Not only can the GC be fixed in simple ways (eg just give us programmers more control over how and when it does its job), but we can do one better than just improving the GC, and it's through marking sections of code as off limits to anything that may allocate, and even better than that in more general terms, prevent the use a feature (or features) of the language that is not appropriate for a marked section of code. That'll make me very happy.


I won't complain about this, but it'll prevent you from being able to call
into a very significant portion of the standard library. Browse through it,
especially the most basic of tools, like std.string, basically everything
allocates somewhere!
I'm not that enthusiastic about fracturing my code into sections that can
make use of the library, and sections that just can't.
A lot of work could be done to make the library not allocate I'm sure,
increasing the amount of library available in these isolated sections
maybe... but I'd rather see work done to add finer control of the GC, so I
can operate it in an acceptable manner.

On 4/10/2013 2:12 AM, Manu wrote:
> Nobody has yet showed me an example of a typical class where it would make ANY
> sense that all (or even most) methods be virtual. (Again, not talking about
> small/trivial or foundational/container classes, people don't write these every
> day, they write them once, and use them for a decade, and they probably like in
> the standard library)

Expression, Statement, Type, and Dsymbol in the compiler sources.

On 11 April 2013 09:23, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/10/2013 4:00 AM, Manu wrote:
>
>> It doesn't have all sources. It could load a library. That can never be guaranteed.
>>
>
> Currently, a virtual call is done with:
>
>    (*vtbl[i])(args...)
>
> It makes me wonder if the following would be faster:
>
>    method_fp = vtbl[i];
>    if (method_fp == &method)
>        method(args...)
>    else
>        (*method_fp)(args...)
>
> Anyone care to dummy this up and run a benchmark?
>

**On a non-x86 machine.
It would depend how derived the class is, but I reckon there's good chance
it would be slower. In the end, the work is the same, but you've introduced
another hazard on top, a likely branch misprediction.
I think the common case with classes is that you're calling through a
base-pointer, so virtual calls become more expensive, and the non-virtuals
may save a cache miss, but gain a misprediction. I suspect the cache miss
(a more costly hazard) would occur less often than the mispredicion, which,
given a greater volume, might add up to be similar.
This is also very, very hard to profile realistically. Isolated test cases
can't reveal the truth on this matter, and in the end, we remain in the
same place, where non-virtual-by-default is clearly better.

It's also possible to, for the per-class static data, have a flag that says
> "isfinal", which is set to false at runtime whenever a new is done for a derived class. Then, the method test above becomes:
>
>     if (isfinal)
>

Branch still exists, vcall is still required if you have a base pointer. Accessors might benefit, but incur the cost of a branch. Aside from virtual (or lack thereof), if() is possibly the second most dangerous keyword ;) It's getting better with time though. Super-long pipeline architectures are slowly dying off.

On 11 April 2013 11:11, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/10/2013 2:12 AM, Manu wrote:
>
>> Nobody has yet showed me an example of a typical class where it would
>> make ANY
>> sense that all (or even most) methods be virtual. (Again, not talking
>> about
>> small/trivial or foundational/container classes, people don't write these
>> every
>> day, they write them once, and use them for a decade, and they probably
>> like in
>> the standard library)
>>
>
> Expression, Statement, Type, and Dsymbol in the compiler sources.
>

The bases? Do you write those classes every day, or are they a tool that you've been using for decade(/s)?

On 4/10/2013 6:20 PM, Manu wrote:
> On 11 April 2013 11:11, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 4/10/2013 2:12 AM, Manu wrote:
>
>         Nobody has yet showed me an example of a typical class where it would
>         make ANY
>         sense that all (or even most) methods be virtual. (Again, not talking about
>         small/trivial or foundational/container classes, people don't write
>         these every
>         day, they write them once, and use them for a decade, and they probably
>         like in
>         the standard library)
>
>
>     Expression, Statement, Type, and Dsymbol in the compiler sources.
>
>
> The bases? Do you write those classes every day, or are they a tool that you've
> been using for decade(/s)?

I modify them constantly. They aren't foundational/container classes, in that they are very specific to the compiler's needs.

On 4/10/2013 3:02 PM, Nick Sabalausky wrote:
> I have noticed that programming and videogames both scratch the same
> mental itch, at least for me. If I've been doing a lot of one, I'm less
> motivated to do the other.


Oddly for me, programming video games kinda wrecked my enjoyment of them. I keep seeing the man behind the curtain instead of the fantasy :-)