[squeak-dev] Re: Using #= for integer comparison instead of #==
eliot.miranda at gmail.com
Wed Nov 17 20:22:17 UTC 2010
On Tue, Nov 16, 2010 at 9:00 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 11/16/2010 8:05 PM, Levente Uzonyi wrote:
>> I wasn't clear when I said atomic code. I expected #= (and #<, #>, etc)
>> to _not_ be a real message send when both the receiver and the argument
>> are SmallIntegers. Otherwise what's the point of having separate
>> bytecodes for them?
> Space. It makes a big difference for the most common selectors (#at:,
> #at:put:, #size, #+ etc) to be be encoded as bytecodes. It avoids having to
> allocate a literal every time you see the selector. Often, the special
> selector bytecodes look like this:
> messageSelector := self specialSelector: 20.
> argumentCount := 1.
> self normalSend.
> I.e., it just dispatches to normalSend where the regular lookup takes
> place. Of course, that also means it's a prime place for an optimization
> that will evaluate eagerly for known receiver types and so (over time)
> optimizations were added, but many of the optimizations that may make sense
> in an interpreter have very different tradeoffs in the jit. For a jit to
> generate the level of optimization makes no sense because the code size
> simply explodes at no benefit if the inline caches are any good (ours *are*
> the best Eliot knows how to do and that is a meaningful statement).
> On to a finer point. The terminology "real message send" is misleading.
> Generally, we (the VM hackers) mean by "real" send a send that requires a
> method activation, i.e., the creation of a context, but *not* the lookup of
> the method. That excludes for example all (successful) primitives from being
> "real sends", and as a consequence writing "1 + 2" is not a real send by
> that measure (with or without the bytecode present) since the primitive will
> be executed successfully and no "real" send (method activation) has taken
I want to disagree slightly. For me the special selector bytecodes are both
a space optimization and a performance opimization, important enough to have
acquired its own term, static type prediction, essentially optimizing by
implementing without lookup the highest dynamic frequency type, which is
what's done for the arithmetic special selector bytecodes, #+, #-, #< #> et
al. What exactly do we mean here? We mean that if the types are of a
particular small set then there is an attempt to perform the operation that
would be performed by a send without actually performing the send, and
falling back to the full send if either an error occurs in the operation or
if the types are invalid. e.g. for #+ we can attempt to perform the
operation if receiver and argument are both SmallIntegers but the result may
overflow. So we send if the types are wrong or if the primitive operation
can't be performed, and the machine falls back on a real send.
Interestingly there is a cost to static type prediction which can make it
not worth-while. If you look at VisualWorks' HPS VM you'll find that there
is no static type prediction for #= and #~= because its dynamic frequency
for SmallInteger is too small. There /is/ static type prediction for #+ #-
#< #<= et al because these selectors are used so frequently in to:do: loops
(unlike #= & ~=).
So I distinguish between the avoidance of the send, the actual send and the
operation the send binds to. The special selector bytecode for #+ can avoid
a real send if the receiver and argument are both SmallIntegers (or in the
interpreter SmallIntegers and/or Floats) /and/ if the result does not
overflow. But it then does a real send to whatever the receiver is.
However that send might bind to a method that has a primitive
(SmallInteger, LargeInteger Float) or not (Fraction, a non numeric object).
The primitive may perform the operation and avoid building an activation.
For example in the Cog JIT it might take too much space to implement static
type prediction for #+ and (SmallInteger | Float) x (SmallInteger | Float)
and instead just implement it for SmallInteger x SmallInteger, but the
primitive for SmallInteger>#+ might quite happily implement SmallInteger x
(SmallInteger | Float). Hence a particular special selector #+ invocation
could end up in either avoiding the send, causing a real send that invokes
the SmallInteger>#+ primitive that succeeds, or a real send that invokes the
SmallInteger>#+ primtiive that fails and builds a frame, or a real send that
invokes a method without a primitive that builds a frame. But all the last
three are real sends.
> To make matters more complicated, when we talk about "real" sends in the
> context of thread switches, semaphores and critical sections, what we mean
> is whether there is a suspension point in the send or not. Obviously, some
> primitives (#suspend, #yield) must have suspension points so not all
> activation-free methods are also suspension-point-free. I am not entirely
> sure what the current set of rules for suspension points in Cog is; in the
> interpreter it was part of the activation sequence so any primitive that
> isn't process related would not have a suspension point but I don't know if
> that's still true in Cog.
Right, I agree. Basically the situation in Cog is that the suspension
points are frame-building sends /not/ marked with primitive 221 or 222
(BlockClosure>valueNoContextSwitch & BlockClosure>valueNoContextSwitch:),
backward branches (i.e. at the end of a while or to:do: loop), and the
Process/Semaphore/Mutex primitives (suspend, yield, wait, signal,
enterCriticalSection, exitCriticalSection). So at backward branches and at
frame build the VM checks for external events which may cause process
switches, but certain primitives may cause suspensions directly.
I suppose my real point is that sends which invoke primitives are still real
sends, but special selector bytecodes that return a result short-circuit
> - Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev