[Vm-dev] #becomeUncompact not longer works in Cog/Stack VMs

[Mariano Martinez Peck]

On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Sat, May 7, 2011 at 7:15 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>
>>
>> On 5/7/2011 9:25, Tobias Pape wrote:
>>
>>> 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.
>>>>
>>> When it worked in pre-cog VMs, why should it break in Cog?
>>>
>>
>> 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.
>>
>
> 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.
>

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?
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.



> 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.
>

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
???


>  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.
>
>
>
>> Cheers,
>>  - Andreas
>>
>>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110508/35641a1b/attachment.htm