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

[Igor Stasenko]

On 8 May 2011 14:39, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>
>
>
> 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.
>

to prove or disprove that you have to check how fast VM with and
without compact classes.


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

yes, it is faster to compare compact class index in OH with constant,
instead of fetching the class of object and comparing it to class
which held in special objects array at certain index.

In fact, i am used the same trick in NativeBoost callout generation.
To test if passed argument is instance of float, its just checks
the object's header and its compact class index value. This is trivial
optimization , which lies on surface.

But then, it is dynamically generated code, which i can discard at any
moment. And if Float will be non-compact next time,
it will generate different code, according to situation.

This means, that it is possible to keep flexibility without
sacrificing speed. And that's what i trying to argue.

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

Me neither.

> --
> Mariano
> http://marianopeck.wordpress.com
>

-- 
Best regards,
Igor Stasenko AKA sig.