Re: objective-c: how slow ?

[Marko Mikulicic]

Malmberg wrote:
> [snip]
>
> > You have manual control over the PIC.
> > Why you can't simply have a macro generate the code in place ?
>
> You don't know what values to use for the class compare/method jump
> until run-time, so you'd have to make a list of all IC:s and patch them
> when the program loads.

The compiler could generate per object information with locations of IC-s,
and the runtime will patch them as the program loads. But this would slow down 
startup if thousands of IC:s are used. An alternative could be placing a full IC
code inline but with the first instruction a jump to the patching routine, which
will restore the first instr. of the IC and update the values known only at 
runime.

> > Is the cost of the JMP to the stub worh ?
>
> 0.5-1 cycles. The unconditional jump is cheap, and lack of conditional
> call instructions means that the stub can be slightly more efficient
> than the IC ('call stub;compare;jz method;jmp lookup' instead of
> 'compare;jmp call_stub;call lookup;jmp cont;call_stub:call
> method;cont:').

You can code the stub like that in the inline code too, you would save
0.5-1 cycles but it would require compiler changes.
Anyway you would be writing in the text segment, which would most
probably arise in a copy on write page fault.


You method has the power/defect to patch whatever caller calls the registered 
methods. Sometimes this can be good, but sometimes this could lead to unexpected
page faulting during execution and core growth.
 Your solution is more easy to implement because the compiler itself needs not 
to be changed but can give serious performance problems that can be hard to 
predict because they depend of the execution profile of the program.

> > > Theoretically, there's recompilation.
> > Sorry, what do you mean ?
>
> Collecting stats on test runs and using the information to inline common
> methods and generate efficient IC:s. Not likely to happen anytime soon.

Can gprof gather useful data for this ?

> [snip]
>
> > Objc has a simpler lookup because it doesn't have multiple inheritance,
> > delegation 
>
> Doesn't forwarding and DO count as delegation?

Not really. Delegation uses the delegate to lookup the method
but forwards the original receiver.
(One example is better than a thousand words. see attachment)

> > and dynamic inheritance.
>
> Those are language limitations. The runtime could handle all of those
> (at least if I'm thinking of the same things you are) at the same speed.

I admit I don't know in detail the lookup mechanism in the objc runtime
but I suppose that rebuilding the sarray after a inheritance change would be 
very expensive. Multiple inheritance requres a resoulution when the same 
selector is found in the ancestors and also handle inheritance cycles. This 
makes the lookup so expensive and also makes any global selector based caching
sheme very difficult to implement.

Maybe I'm wrong. Do you think all these can be handled by the objc runtime ?
Can methods be added at runtime to the cache (suppose they were builded runtime 
by byte-code) ? I could be very easy to implement a RAD tool for objc,
or even implement a Smalltalk or Self system on top of the objc runtime
(which would have goot C interfacing though objc/openstep wrappers) ?

Marko