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

[Henrik Sperre Johansen]

On 26.11.2009 23:26, Eliot Miranda wrote:
>   
>
>
> Hi Levente,
>
> On Thu, Nov 26, 2009 at 12:01 PM, Levente Uzonyi <leves at elte.hu 
> <mailto: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
>
>
FWIW, I'd take a JIT anyday over this bug getting fixed :)
On the other hand, it's a one-word fix which merely improves performace 
while we're waiting (unless someone decides to remove the primtive calls 
from the image altogether, then it merely becomes obsolete), so I hardly 
see the harm in applying it.

Cheers,
Henry

PS. Speaking of unneccessary overhead, what about that collection class 
== ByteString part for _every_ stream nextPut: , when ByteString at:put: 
will handle the case correctly anyways if collection is in fact a 
ByteString? Not to mention how it performs for ByteString currencly, 
seeing as the primitive now _does_ fail every time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20091127/5a6087d2/attachment.htm