Groups | Search | Server Info | Login | Register
Groups > comp.lang.forth > #22756
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Subject | Re: OO dispatch |
| Newsgroups | comp.lang.forth |
| References | (9 earlier) <2013May2.162843@mips.complang.tuwien.ac.at> <klu9fd$ifv$1@online.de> <kn0aqb$d3v$1@online.de> <R5CdndY-5plDUg7MnZ2dnUVZ_hOdnZ2d@supernews.com> <2013May16.160704@mips.complang.tuwien.ac.at> |
| Message-ID | <ut-dnUpWOM9YygrMnZ2dnUVZ_t-dnZ2d@supernews.com> (permalink) |
| Date | 2013-05-18 05:28 -0500 |
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. So, it corresponds with a word that has multiple definitions depending on the type of TOS (or the current object.) This is quite neatly implemented with a hash table and some caching. Note that this does not imply classes or inheritance, just that everything can be identified as having a type. It applies to pretty much any model of OOP you can think of, so it's ideal as a primitive. >>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. >>> My guestimate is that a >>> >>> if(class==constant) then call <method> else rewrite_polymorphic(); fi >>> >>> is at least one cycle worse on a Core i7 than a predicted vtable call, >>> because the Core i7 can't do two branches in one cycle. >> >>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. > 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. Sure, this form is nice for icache density. > The nice thing here is that this can be (and, by VFX, is) inlined at > the call site, which increases the prediction accuracy. Absolutely. I wouldn't do it any other way. Andrew.
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
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