<br><br><div class="gmail_quote">On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><br><div class="gmail_quote">On Sat, May 7, 2011 at 7:15 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 5/7/2011 9:25, Tobias Pape wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact.<br>
</blockquote>
When it worked in pre-cog VMs, why should it break in Cog?<br>
</blockquote>
<br></div>
Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them.<br>
</blockquote><div><br></div><div>Thank you Andreas. Exactly. Determining the class of an instance of a compact class is faster than determining the class of an instance of a non-compact class if the compact class index is known. </div>
</div></blockquote><div><br>This is what I don't understand. Even if the compact class index is known, why is it that faster than non-compact? because in non-compact you need to fetch the class pointer from the object header?<br>
But... regardless that the compact class index is know, you also have to get the index (those 5 bits) from the OH. So I don't see why there is so much difference in performance. <br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>So in asking "is the receiver a LargeInteger" or "is the receiver a Float" in the VM is significantly faster if the compact class index is a constant. </div></div></blockquote>
<div><br>You mean that to answer "is the receiver a LargeInteger" you don't need to fetch the class of the receiver and then do a speObj: comparison, but instead get the compact class index from the OH and compare to a known value ???<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div> If we introduce the in-practice unused facility to allow all classes to become uncompact we lose this performance advantage. I do not see the point of losing performance to support unused or useless functionality.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>