Re: Proposal: runtime-modifying Kernel methods should be keywords

On 16/07/07, John Lam (CLR) <[e-mail]> wrote:
> > PS: Incidentally... The comment on the blog entry you gave above
> > mentions call site caches. I had a student try that for Ruby, and he
> > found that it couldn't beat Ruby's built-in cache. The reason is
> > probably the simplicity of Ruby's cache, excellent hardware cache
> > behavior, and a good cache hit-rate.
>
> Not sure what you mean by this - are you saying that the call site method caches did not improve perf at all in a modified version of Ruby?

Yes and no. Ruby already has a built-in cache. It is a single table,
and the entry for a certain method lookup is calculated as a hash of
the class pointer and the method ID. This is a really simple caching
method that in theory could be really bad but in practice turns out to
work really well. So *replacing* this cache with call site caches
actually decreases performance, although we both know that in theory
(disregarding hardware caching effects and all) it should make
performance better. Obviously, the call site cache is better than no
cache. I just wanted to point out that call site caches are not
necessarily the best caching mechanism, so if sometime in the future
you are implementing some method caching mechanism you might want to
take a look at Ruby's (if you're allowed ;-). Its performance may be
specific for Ruby though, but it seems to be less of a function of the
exact lookups being done than of hardware cache behavior.

For your interest, the cache size in Ruby is 4K entries, and this
seems to be close to optimal. Increasing the size usually decreases
performance, which again points in the direction of the hardware cache
being at work.

Peter