A dynamic call site is an object that takes a certain number of arguments and a
kind of description of how to combine those arguments into a result. The
"description" (also known as the call site binder) generates code that is
stored in the call site and keyed on some property of the arguments -- usually
the type. So a call site that's used to perform a "less than" operation must be
attached to code that knows how to look at two arguments and generate IL which
will determine whether the first arg is less than the second one (or, if the
comparison is not valid, IL which will throw an exception).
Now let's say you have a bit of Ruby that says "c = a < b". When the IronRuby
compiler generates code for this, it doesn't know what the types of "a" and "b"
are, so it can't emit the actual comparison. Instead, it creates a call site
that takes two arguments and returns a result, and it attaches this call site
to a binder that says "call the < function that's defined on the first object".
The first time the code is executed, a = 1 and b = 3. The binder looks at the
type of a and determines that it should call Fixnum.<, so it creates code in
the form of a delegate which will do that (let's name this "CALL1"), and will
store that delegate in the call site along with a test ("TEST1") which
indicates when that delegate is valid.
The next time the code is executed, a = 3 and b = 7. The call site executes
TEST1, which returns a positive result so it uses CALL1 to execute the
comparison. The binder does not get involved.
The third time the code is executed, a = "hello" and b = "world". TEST1 fails,
so the call site asks the binder to analyze the new situation and come up with
a TEST2 and CALL2 that will call String.< for an argument of type string.
All of this is basically DLR 101, so I'm sorry if it's stuff you already know
:).
Now it should be pretty obvious that a call site's performance degrades as it
sees a greater variety of types. The site has more and more TEST methods to run
before it gets a positive result or knows that it has to fall back to the
binder to generate new code.
Consider a method like Array.sort. This method needs to perform comparisons on
individual array elements of arbitrary type. That means that a dynamic call
site needs to be involved. In earlier versions of IronRuby, we only had two
choices -- use a single call site that's shared between all calls to
Array.sort, or create a new site each time sort is called. The former approach
suffers from the problem of "going megamorphic", that is, having too many tests
to be called for each comparison. But with the latter, we lose out on some
efficiency because we need to create a new call site and run the binder code at
least once for every call to sort.
The CallSiteStorage mechanism adds a third option. It allows the library author
to push the location of the call site cache up to the place where Array.sort is
actually called. This then creates a situation that is much more like the one
for "c = a < b"; there's a one-for-one relationship between the call site in
user code and the call site cache. This is a good level for caching, because
any given array in user code that calls "sort" is very likely to contain
elements of only a single type or small number of types.
So to answer your questions more specifically,
1. The IronRuby compiler automatically creates three BinaryOpStorage objects
for each call to Array.sort -- one for each of the three parameters which have
that type -- and emits code to insert those parameter onto the call stack
before calling ArrayOps.Sort.
2. The BinaryOpStorage object is not tied to a specific operation at creation;
it's just a cache. It's how the BinaryOpStorage is used that determines the
kind of code stored in the cache.
3. Specifically, if you trace the code path into Protocols.Compare and
Protocols.ConvertCompareResult, you'll see that these storages are initialized
with calls to "<=>", "<" and ">", respectively.
4. The names of the parameters are irrelevant. :)
There's a general lesson here -- the DLR is like porridge; it's best when it's
neither too hot nor too cold.
From: ironruby-core-boun...@rubyforge.org
[mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Shay Friedman
Sent: Saturday, October 17, 2009 11:14 PM
To: ironruby-core@rubyforge.org
Subject: [Ironruby-core] CallSiteStorage for [RubyMethod]
Hi,
I'm working on a native extension by writing an IronRuby library in C#. I hit
the wall with the CallSiteStorage parameters that can optionally come as the
first 0 or more parameters for a ruby method.
What are they and what's their use? I tried to understand that from their
current uses accross the code by I couldn't understand how IronRuby knows what
to set there.
For example, this is from ArrayOps:
[RubyMethod("sort")]
public static object Sort(
BinaryOpStorage/*!*/ comparisonStorage,
BinaryOpStorage/*!*/ lessThanStorage,
BinaryOpStorage/*!*/ greaterThanStorage,
BlockParam block, RubyArray/*!*/ self) {
...
...
}
How does IronRuby knows that the first should be a comparison storage, the
second a less-than storage and the third a greater-than storage? is it because
of the name of the parameter?
Thanks!
Shay.
--
--------------------------------------------------
Shay Friedman
Author of IronRuby Unleashed
http://www.IronShay.com
Follow me: http://twitter.com/ironshay
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
