John wrote:

>> I believe on most modern processors integer multiplies are single
>> cycle instructions, just like shifts. On top of this, the Squeak
>> << operator is not quite a primitive (it does a test, then calls
>> the primitive), so there is one extra message send plus a few
>> other bytecodes. Try using "bitShift:", which is a primitive,
>> and you should see more comparable performance.

Not quite yet.  The fastest integer multiplies are still around 3 to 5 
cycles of latency, but can be pipelined (and proceed in parallel with 
other instructions).  Many implementations are slower than this, e.g. 
radix-4 modified Booth that would take 16 to 18 processor cycles for a 
32-bit multiply.


Andreas replied:

>But probably not that of bytecodeMultiply since #bitShift: as well as #<<
>require a message lookup in the class. And compared to a few machine
>cycles for integer multiplication this is quite a lot.

Yes, that's the real reason: SmallInteger arithmetic is important and 
frequent enough that the system is heavily optimized for it.  The 
Compiler generates special bytecodes that attempt to perform SmallInteger 
arithmetic (and sometimes Float arithmetic, if that fails) directly 
without going through the standard method lookup that message sends 
normally do.  Only if those fail is the standard lookup performed.  This 
means that if you implement #* for one of your own objects, it will be 
slightly slower than a message named something else, say #times: -- but 
that is a good tradeoff to make for the increased performance of 
SmallInteger arithmetic.



     -- tim