> I tested speed of various calling methods with http://www.xs0.com/d/ifaces.d.html
>
> and here are the results I get:
>
>               Normal:             12165450 / sec
>    Through interface:             11764706 / sec
>    Lookup every time:              9580379 / sec
>     Optimized lookup:             13390466 / sec
>     Static functions:             13224015 / sec
>
> The number is function calls / second.
>
> With a function of any significant complexity, the differences would be even smaller, and even here it's just around 20% in the worst case. And if a simple observation* is implemented in the optimizer, the speed loss in fact becomes speed gain (ok, in reality it would also be implemented for non-interface methods, so the speed would end up the same).
>
> *) if the object reference doesn't change neither can the function pointer

ok, I see what you mean. thanks for explaining. Pretty cool! Since the vtable lookup is linear in the total number of interfaces the class implements (including the interfaces of super-interfaces) it could be more noticeable in larger examples.

>>> On the other hand, if interface references point to a different address than class references, you need to store offsets somewhere, have to modify the address on every call, need to handle implicit conversions when passing function boundaries, etc. etc.
>>
>> This technique I'm used to. It's called thunking and I believe it's the
>> standard
>> way of implementing MI and/or interfaces. That is, when a class
>> implements an
>> interface method it makes a thunk to adjust the 'this' pointer before
>> calling
>> the actual class method. So when you have an interface A and class C and
>> call a
>> method f in A that is implemented in C the slot in the vtable for f
>> (which takes
>> an A) calls the thunk to adjust the A to a C and then the thunk jumps to
>> the
>> method (which takes a C).
>
> Well, I think there's a significant difference between MI and interfaces in that interfaces only allow methods, while with MI you also have fields to think of. Having to basically make a function call for each field access would indeed be too inefficient, but it's not the same case with methods, because the call itself usually takes only a (very) small part of total method execution time.

In general I agree function call speed isn't a big deal for interfaces but it isn't unusual to have an interface that abstracts out a field lookup (eg, getLength). For those the body of the implementation would be very simple. I'm curious if the double lookup technique has been tried in practice and what the impressions were.

Ben Hinkle wrote:
> In general I agree function call speed isn't a big deal for interfaces but it isn't unusual to have an interface that abstracts out a field lookup (eg, getLength). For those the body of the implementation would be very simple. I'm curious if the double lookup technique has been tried in practice and what the impressions were.

Does any commonly used language / compiler implement these double lookups?


Like xs0 said, the decrease in overall speed is ridiculously small. Most (non-pro guru) Java programmers I know of use interfaces this way a lot despite the obvious drawbacks in performance. I think that beefing up the compiler logic just a little bit here pays itself back faster than we can even imagine. At least it makes the life of application programmers and thus end users a bit easier (better modularity, less error-prone casting).

To me it sounds a bit weird that Walter has promised to implement array literals, but interfaces are going to be left broken. They're can be both implemented now by using template hacks and seem to be equally hard to implement.

-- 
Jari-Matti

Ben Hinkle wrote:
> ok, I see what you mean. thanks for explaining. Pretty cool! Since the vtable lookup is linear in the total number of interfaces the class implements (including the interfaces of super-interfaces) it could be more noticeable in larger examples.

Well, the lookup need not be linear. Since the interfaces are known in advance for each class, it should be possible to achieve a fast O(1) lookup with something like a [minimal] perfect hash function, all you'd probably need is some sort of numeric identifier for each interface (could simply be a MD5 of its full name or something).

> In general I agree function call speed isn't a big deal for interfaces but it isn't unusual to have an interface that abstracts out a field lookup (eg, getLength). For those the body of the implementation would be very simple. I'm curious if the double lookup technique has been tried in practice and what the impressions were.

Well, as far as I can tell, Sun's JVM does something like this (at least the timing results seem to suggest so), and considering how often interfaces get used in Java, I'd say it's not actually a significant problem.

Though I've no idea if any compiled language does so, as I don't know that many :)

It should also be noted that having a single reference to each object would allow covariance in many more cases, so it'd be easier to actually have a class reference than it is now..


xs0

Walter Bright wrote:
> Stewart Gordon wrote:
>> Walter Bright wrote:
>>> Mostly bug fixes.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>
>> "Shadowing local variable declarations is now deprecated."
>>
>> I thought it had always been illegal by the spec.
> 
> It wasn't implemented.

So you've implemented it as a deprecation for the time being, rather than banning it altogether?

<snip>
>> "Fixed Bugzilla 57  in 0.151"
>>
>> Why is this in the changelog for 0.161?
> 
> It was overlooked.

What do you mean?  The changelog for 0.151 also lists this bug as fixed.

>> "Fixed Bugzilla 36  (better error message)"
>> "Fixed Bugzilla 85  (now issues error message)"
>>
>> And they're also marked as fixed in Bugzilla.  However, at the moment I can't seem to find the bit of the spec that indicates that either is illegal code.
> 
> 36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead.

Nobody else I know would claim that changing the error message resulting from a bug constitutes fixing the bug.

If the bug _is_ the bad error message, rather than the fact that an error is produced at all, then that's another matter.

> 85: It can't be made to work, because an interface handle is different from a class handle.

But it can be made to create a new array of the interface type.  But this should probably require an explicit cast.

Just looking at the documentation, the "Implicit Conversions" section of arrays.html mentions "U[] where U is a base class of T" - I now suppose it's just a temptation to think that it would work on interfaces as well.  Clarification would certainly be welcome.

And we could also do with some decent documentation on what arrays may be converted to by explicit casting.

> It doesn't work in C++, either, for the same reasons.

Since when has C++ had interfaces?

Stewart.

xs0 wrote:
> Ben Hinkle wrote:
> 
>> ok, I see what you mean. thanks for explaining. Pretty cool! Since the vtable lookup is linear in the total number of interfaces the class implements (including the interfaces of super-interfaces) it could be more noticeable in larger examples.
> 
> 
> Well, the lookup need not be linear. Since the interfaces are known in advance for each class, it should be possible to achieve a fast O(1) lookup with something like a [minimal] perfect hash function, all you'd probably need is some sort of numeric identifier for each interface (could simply be a MD5 of its full name or something).
>


I would expect that the pointer-to-vtbl for the interface would be placed in the classes vtbl. class to interface cast would consist of (in sudo code)


/** i = c;  **/

interface_Ijk_Struct i;
with (i)
{
	contextPtr = c;
	vtbl = c.vtbl[Ijk_Vtbl];
}

////// What am I missing?
	

On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:

> Walter Bright wrote:
>> Stewart Gordon wrote:
>>> Walter Bright wrote:
>>>> Mostly bug fixes.
>>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> "Shadowing local variable declarations is now deprecated."
>>>
>>> I thought it had always been illegal by the spec.
>> 
>> It wasn't implemented.
> 
> So you've implemented it as a deprecation for the time being, rather than banning it altogether?

Walter's actions here made sense to me. A lot of people had begun to think
that the bug lay in the documentation and not the implementation, and so
coded accordingly. Now, rather than force them to immediately change all
their source code, Walter has allowed them a way to gradually convert to
the real specification.


>>> "Fixed Bugzilla 36  (better error message)"
>>> "Fixed Bugzilla 85  (now issues error message)"
>>>
>>> And they're also marked as fixed in Bugzilla.  However, at the moment I can't seem to find the bit of the spec that indicates that either is illegal code.
>> 
>> 36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead.
> 
> Nobody else I know would claim that changing the error message resulting from a bug constitutes fixing the bug.

It could be argued that #36 remain as 'open' so that the underlying bug is eventually fixed. However, now that the message text has changed (improved?) it might be better for us to open a new bug entry, using the new message in the commentary, to keep this issue on Walter's TODO list.


> And we could also do with some decent documentation on what arrays may be converted to by explicit casting.

As you may have noticed, Walter often gets a bit busy. It might then be a reasonable idea for you, or anyone else, to have a go at writing this documentation update and sending it to Walter for merging into the main documentation body.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
23/06/2006 9:17:40 AM

Derek Parnell wrote:
> On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:
[...]
> 
>>And we could also do with some decent documentation on what arrays may be converted to by explicit casting.
> 
> 
> As you may have noticed, Walter often gets a bit busy. It might then be a
> reasonable idea for you, or anyone else, to have a go at writing this
> documentation update and sending it to Walter for merging into the main
> documentation body.
> 

How do you get DMD to let you use depreciated "things"? I know it's in there somewhere but I can't seem to find the switch.

On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:

> Derek Parnell wrote:
>> On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:
> [...]
>> 
>>>And we could also do with some decent documentation on what arrays may be converted to by explicit casting.
>> 
>> As you may have noticed, Walter often gets a bit busy. It might then be a reasonable idea for you, or anyone else, to have a go at writing this documentation update and sending it to Walter for merging into the main documentation body.
>> 
> 
> How do you get DMD to let you use depreciated "things"? I know it's in there somewhere but I can't seem to find the switch.

Use the "-d" switch. Documented under "Tools / DMD D Compiler"
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
23/06/2006 10:28:15 AM

Stewart Gordon wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
>>> Walter Bright wrote:
>>>> Mostly bug fixes.
>>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> "Shadowing local variable declarations is now deprecated."
>>>
>>> I thought it had always been illegal by the spec.
>>
>> It wasn't implemented.
> 
> So you've implemented it as a deprecation for the time being, rather than banning it altogether?

Yes, because it breaks a lot of existing code.

>>> "Fixed Bugzilla 57  in 0.151"
>>>
>>> Why is this in the changelog for 0.161?
>>
>> It was overlooked.
> 
> What do you mean?  The changelog for 0.151 also lists this bug as fixed.

Yes, but it was left open in bugzilla.


>>> "Fixed Bugzilla 36  (better error message)"
>>> "Fixed Bugzilla 85  (now issues error message)"
>>>
>>> And they're also marked as fixed in Bugzilla.  However, at the moment I can't seem to find the bit of the spec that indicates that either is illegal code.
>>
>> 36: forward references are an ongoing issue, I'd like to get rid of all such errors. But in the meantime, having feet of clay, some will give error messages instead.
> 
> Nobody else I know would claim that changing the error message resulting from a bug constitutes fixing the bug.
> If the bug _is_ the bad error message, rather than the fact that an error is produced at all, then that's another matter.

Giving clear error messages takes care of the problem for now.


>> 85: It can't be made to work, because an interface handle is different from a class handle.
> 
> But it can be made to create a new array of the interface type.  But this should probably require an explicit cast.
> 
> Just looking at the documentation, the "Implicit Conversions" section of arrays.html mentions "U[] where U is a base class of T" - I now suppose it's just a temptation to think that it would work on interfaces as well.  Clarification would certainly be welcome.
> 
> And we could also do with some decent documentation on what arrays may be converted to by explicit casting.
> 
>> It doesn't work in C++, either, for the same reasons.
> Since when has C++ had interfaces?

Multiple inheritance is a superset of interfaces.

Derek Parnell wrote:
> On Thu, 22 Jun 2006 17:31:16 -0700, BCS wrote:
> 
>> Derek Parnell wrote:
>>> On Thu, 22 Jun 2006 17:11:07 +0100, Stewart Gordon wrote:
>> [...]
>>>> And we could also do with some decent documentation on what arrays may be converted to by explicit casting.
>>> As you may have noticed, Walter often gets a bit busy. It might then be a
>>> reasonable idea for you, or anyone else, to have a go at writing this
>>> documentation update and sending it to Walter for merging into the main
>>> documentation body.
>>>
>> How do you get DMD to let you use depreciated "things"? I know it's in there somewhere but I can't seem to find the switch.
> 
> Use the "-d" switch. Documented under "Tools / DMD D Compiler"

And under the dmd command line help. BCS, that was hard to miss. *g*

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D