<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 10:33 AM, Igor Stasenko <span dir="ltr">&lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On 17 April 2012 19:14, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 17, 2012 at 9:54 AM, Igor Stasenko &lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Performance, yes...<br>
&gt;&gt;<br>
&gt;&gt; But i wonder, how much performance we will lose by having more<br>
&gt;&gt; flexible implementation for ByteString..<br>
&gt;&gt;<br>
&gt;&gt; So, here what i did:<br>
&gt;&gt;<br>
&gt;&gt; ByteString&gt;&gt;bat: index put: aCharacter<br>
&gt;&gt;<br>
&gt;&gt;        ^ aCharacter putIntoByteString: self at: index<br>
&gt;&gt;<br>
&gt;&gt; Character&gt;&gt;putIntoByteString: string at: index<br>
&gt;&gt;<br>
&gt;&gt;        ^ value &lt; 256<br>
&gt;&gt;                ifTrue: [ string basicAt: index put: value ]<br>
&gt;&gt;                ifFalse: [  string at: index put: self ]<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Now benchmark:<br>
&gt;&gt;<br>
&gt;&gt; | s chars |<br>
&gt;&gt;<br>
&gt;&gt; s := ByteString new: 1000.<br>
&gt;&gt; chars := (1 to: 255) collect: [:i | Character value: i ].<br>
&gt;&gt;<br>
&gt;&gt; [<br>
&gt;&gt; 1 to: 1000 do: [:i |<br>
&gt;&gt;        chars do: [:char| s at: i put: char ]<br>
&gt;&gt;        ].<br>
&gt;&gt; ] bench<br>
&gt;&gt;<br>
&gt;&gt;  &#39;105 per second.&#39;<br>
&gt;&gt;<br>
&gt;&gt; | s chars |<br>
&gt;&gt;<br>
&gt;&gt; s := ByteString new: 1000.<br>
&gt;&gt; chars := (1 to: 255) collect: [:i | Character value: i ].<br>
&gt;&gt;<br>
&gt;&gt; [<br>
&gt;&gt; 1 to: 1000 do: [:i |<br>
&gt;&gt;        chars do: [:char| s bat: i put: char ]<br>
&gt;&gt;        ].<br>
&gt;&gt; ] bench<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;  &#39;91.9 per second.&#39;<br>
&gt;&gt;<br>
&gt;&gt; ~10%...<br>
&gt;&gt;<br>
&gt;&gt; Such kind of difference is IMO laughable,<br>
&gt;<br>
&gt;<br>
&gt; I disagree.  10% is a significant loss of performance.  It can take huge effort to gain 10% in a VM implementation.  It is not at all laughable.  Cog is significantly faster than the Interpreter (by factors of 3 or 5).  And that performance difference is worth-while.  The straw man below isn&#39;t a convincing argument either.  I don&#39;t see what is wrong with using a slower more flexible VM for bootstrapping (or indeed a simulation, or ...).  But do we really have to spend time arguing this point?  If you think you can do better, then  do so.  Build a more flexible VM.  Then we can compare the two.<br>

<br>
</div></div>Calm down, Eliot. I am not challenging and don&#39;t want to be<br>
challenged. Yes, we can squeeze 1 or 2 % here and there, but at costs<br>
of having additional constraints/contracts like compact classes,<br>
ifTrue/ifFalse inlining etc.. which , if we follow that path all the<br>
way, we end up with strongly typed system like C or Java and little<br>
room for smalltalk powers.<br></blockquote><div><br></div><div>I&#39;m not uncalm :)  I just get frustrated with these performance arguments, having a coherent vision for better performance and having failed to make satisfactory progress.  The better object representation followed by more machine-code primitives step will get another factor of 2 and result in a simpler VM (immediate characters for example).  Speculative inlining/adaiptive optimizing in Smalltalk will get another factor of 3.  But I&#39;m not paid to work on these things.  And I find having discussions about small points like this adds to my frustration because they&#39;re not getting us very far and I feel I&#39;m wasting my breath.  Sorry...</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The good question is where to put optimizations to not constrain the<br>
system more than necessary and do not sacrifice flexibility in favor<br>
of speed.<br></blockquote><div><br></div><div>Right.  Better object representation, followed by speculative inlining.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5"><br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>