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

Igor Stasenko siguctua at gmail.com
Sat May 7 20:30:19 UTC 2011


On 7 May 2011 16:15, 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.

Where is the metrics?
I need to know what we lose if we do it one or another way.

And since Cog don't allows me to turn compact class back to be normal
class (simply crashing),
i cannot measure it.

> Therefore, some classes
> cannot be made non-compact in Cog, and that is a perfectly good tradeoff.

In theory. But you have no proof now.
Why i should trust you/Eliot/anyone else, without being able to test it?


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

It was not necessary to ban uncompaction.
I would ban a creation of new compact classes, but not turning compact
one to be uncompact again.

Also, i don't want to do anything with old Interpreter. It makes no
sense to see % slowdown in old interpreter
and assume you will have same for Cog. It can be completely different.
Comparing Interpreter and Cog is like comparing apples and oranges.

I wanted to do a simple experiment:
 - create an image which has no compact classes
 - modify cog to not use compact class header

so i can measure pro and cons..

Now , it looks like i cannot do it in simple way, because Cog simply
cannot run such image(s),
because some code in Cog are nailed down presence of concrete compact classes.


-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list