<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 26.11.2009 23:26, Eliot Miranda wrote:
<blockquote
cite="mid:3ac5ce8a0911261426u7d9646ahca378b73f7ddbdd0@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
Hi Levente,<br>
<br>
<div class="gmail_quote">On Thu, Nov 26, 2009 at 12:01 PM, Levente
Uzonyi <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:leves@elte.hu">leves@elte.hu</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On Thu, 26 Nov 2009, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<br>
</blockquote>
<br>
</div>
We are using these primitives in our own stream implementation like
this:<br>
<br>
next<br>
<br>
<primitive: 65><br>
[ position < readLimit ] whileFalse: [ self receiveData ].<br>
^buffer at: (position := position + 1)<br>
<br>
And it does make a difference (buffer is a 8kiB sized ByteArray). Would
this be faster without the primitive?<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Since the Cog JIT isn't available yet I'm not really being
helpful. I should think before I blurt. Apologies.</div>
<div><br>
</div>
<div>Eliot</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font
color="#888888">
<br>
Levente<br>
</font></blockquote>
</div>
<br>
</blockquote>
FWIW, I'd take a JIT anyday over this bug getting fixed :)<br>
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.<br>
<br>
Cheers,<br>
Henry<br>
<br>
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.<br>
<br>
</body>
</html>