[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.

Eliot


> 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