Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #22837

Re: OO dispatch

Show all headers | View raw

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 
>>>>> But even if vtable dispatch is somewhat better, a cacheing "virtual
>>>>> function" approach is much more general-purpose, for very little
>>>>> extra cost.
>> 
>> What is 'a cacheing "virtual function" approach'?
>
>My apologies, I was inconsistent in my use of terminology.
>
>I was thinking of something very much like a generic function (in LISP
>terminology), which is a function that is specialized on the type of
>its operand.  This is a fairly general-purpose concept that IMO is
>ideal for Forth.

It can be implemented with vtable dispatch, so it's not an alternative
to it, but a concept at a different level.

>This is quite neatly implemented with a hash table and some caching.

So that's the implementation you were thinking of.  Still not a clear
enough description that I could discuss it.

>>>Nothing, save for the fact that you're hoping for good prediction and
>>>neglecting the cache miss effects when fetching from the vtable.  The
>>>prediction of an inline cache is going to be far better.
>> 
>> Have you measured it?
>
>No, but it's not going to be any worse (how could it be?) and it's not
>limited to a fixed-size cache.

The way you describe it below, you only use inline caching for
monomorphic methods.  There, your check branch will predict perfectly,
and the BTB (or more sophisticated indirect branch predictor) will
also predict perfectly; at least if we ignore aliasing in the
predictors, and of course the warmup time of the predictor (including
after task switches).

Of course, if we do not ignore these issues, it's easy for one scheme
to be faster than the other in a specific case, and the other way
round for another case.  And if we also look at polymorphic calls,
things become more interesting.  There is certainly no guarantee that
the prediction is better for a particular scheme.

>>>That's not what we do.  It's
>>>
>>>   mov r1, #constant
>>>   call method
>>>   ...
>>>   mov r2, [obj]
>>>   cmp r2, r1
>>>   bne ...
>> 
>> Please elaborate.  Is the stuff you show after the "call method" the
>> content of "method"?
>
>Yes.
>
>> What happens after the bne?
>
>The method.
>
>> Where does the bne branch to?
>
>The miss handler.  At that point the call site is rewritten to
>polymorphic dispatch.

So that code is only used for monomorphic methods.  Ok, but that's not
very general.

>
>> Just to give a comparison, the code for VFT dispatch (as generated by
>> VFX) is:
>> 
>> ( 080BFEA0    8B13 )                  MOV       EDX, 0 [EBX]
>> ( 080BFEA2    FF5208 )                CALL      [EDX+08]
>> 
>> 2 instructions, 5 bytes.
>
>Right, but there's an indirect fetch and jump in there.

None of which are on the critical path in an OoO CPU, if the branch is
predicted correctly.


-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-15 16:46 +0200
  Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-15 13:11 -0500
    Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-15 23:23 +0200
      Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-16 02:24 -0500
        Re: The current object anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-16 13:55 +0000
        Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-16 17:45 +0200
          Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-18 05:13 -0500
            Re: The current object Doug Hoffman <glidedog@gmail.com> - 2013-05-18 06:43 -0400
            Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-18 10:03 -0500
              Re: The current object Doug Hoffman <glidedog@gmail.com> - 2013-05-18 11:30 -0400
              Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-19 01:20 +0200
                Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-19 12:33 -0500
            Re: The current object Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-19 01:07 +0200
              Re: The current object Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-19 03:58 -0500
    OO dispatch (was: The current object) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-16 14:07 +0000
      Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-18 05:28 -0500
        Re: OO dispatch anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-20 11:28 +0000
          Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-20 09:00 -0500
            Re: OO dispatch Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-21 01:37 +0200
              Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-21 03:21 -0500
            Re: OO dispatch anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-21 12:24 +0000
              Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-21 10:18 -0500
                Re: OO dispatch anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-05-21 16:03 +0000
                Re: OO dispatch Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-05-21 12:55 -0500
                Re: OO dispatch Bernd Paysan <bernd.paysan@gmx.de> - 2013-05-29 00:00 +0200
                Re: OO dispatch Mark Wills <markrobertwills@yahoo.co.uk> - 2013-05-28 15:49 -0700

csiph-web