[Vm-dev] Bug in Interpreter>>primitiveNextPut:

Eliot Miranda eliot.miranda at gmail.com
Thu Nov 26 22:26:37 UTC 2009

Hi Levente,

On Thu, Nov 26, 2009 at 12:01 PM, Levente Uzonyi <leves at elte.hu> wrote:

> On Thu, 26 Nov 2009, Eliot Miranda wrote:
>> I wouldn't bother trying to fix the primitive.  Both in VisualWorks and at
>> Teleplace the experience has been the same, getting rid of the primitives
>> for next, nextPut: and atEnd sped things up.  The system is simply too
>> complex nowadays for these primitives to pay for themselves because they
>> only cover a small number of cases.  The primitives support Array and
>> ByteString bow there are so many different kinds of arrays being streamed
>> over that the cost of primitive failures outweigh the benefits of primitive
>> successes.
> We are using these primitives in our own stream implementation like this:
> next
>        <primitive: 65>
>        [ position < readLimit ] whileFalse: [ self receiveData ].
>        ^buffer at: (position := position + 1)
> And it does make a difference (buffer is a 8kiB sized ByteArray). Would
> this be faster without the primitive?

I can't guarantee it.  You'd have to measure.  All I can say is that we
found it better to get rid of the stream primitives in VisualWorks and in
the Cog JIT.  Looking at the Squeak VM code I think the primitives will
still win in the interpreter; after all they use the same machinery as at:
and at:put:.  But in a JIT they'll likely loose.

Since the Cog JIT isn't available yet I'm not really being helpful.  I
should think before I blurt.  Apologies.


> Levente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20091126/4eb18239/attachment.htm

More information about the Vm-dev mailing list