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

[Igor Stasenko]

2009/11/27 Eliot Miranda <eliot.miranda at gmail.com>:
>
> 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.

Apologies accepted. ;)
Nevertheless, i think that reducing the set of VM responsibilities by
moving them to image side is a good tendency, because the less
classes/formats VM knows about , the less complex it is, and system is
more flexible.

> Eliot
>>
>> Levente
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.