discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: objective-c: how slow ?


From: Marko Mikulicic
Subject: Re: objective-c: how slow ?
Date: Sat, 01 Sep 2001 14:12:19 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801

Nicola Pero wrote:
>>does the current objc compiler/runtime optimizes in some way
>>message lookups (inline caches, polymorphic inline caches,...).
>>
>
>>PS:
>>Polymorphic inline caches  (PIC) have the cost of a test and a direct
>>jump in the best case (cache hit) and 3 or 4 tests (pipelined) and a
>>normal method lookup. There could be performance issues because of the
>>self-modifying code (icache flushes) but a cache update should not
>>happen frequently.
>>Please refer to the Self prototyping OO language implementation,
>>and documentation for furhter informations look at:
>>http://www.sun.com/research/self/
>>
>
> Thanks for the pointers, I didn't know about that and it was a very
> interesting reading.
>
> Plainly, my answer is to your suggestion of using inline caches in the
> Objective-C runtime is that the current Objective-C runtime can message at
> a very high speed in multithreading, in a totally thread-safe way.  The
> current method cache is amazingly designed in such a way to run
> thread-safe without locks, thus it is thread safe without incurring *any*
> thread lock overhead.
>
> My feeling reading about inline caches is that they require self-modifying
> code, and for the solution to be viable you would need to have
> self-modifying code which can run multithreading in a thread-safe way
> without using locks (as adding thread locking would kill the performance).
> It might actually be possible to implement it, but if it is, it is not
> going to be trivial.
>

Self was designed to use a soft theading having a context switch exactly at the
beginning of a method (faking the stack overflow test in the prologue). Since
Self uses message dispatching for quasi everything (although massive inlining,
could defeat the responsiveness, but that's unlikely to happen), this provides
fine granularity and avoids locking. However, only one processor is exploited.
This may be good for a experimental system, but for production native threading
should be used and a way of implementing PICs using native threads. (also the
stack overflow stuff should be done using page faults).
  I'm working on that. When done for OpenSelf maybe it could be ported to gcc 
objc.

  How does the runtime cache work ?
  Is there currently a big impact on performance when adding new methods at
runtime ?
  Could it support multiple inheritance, delegation, dynamic inheritance ?


Marko





reply via email to

[Prev in Thread] Current Thread [Next in Thread]