[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