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

[Andreas Raab]

On 5/7/2011 22:30, Igor Stasenko wrote:
>
> 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.

Then write the code yourself. Why does Eliot have to do that? His 
metrics is pretty simple, a comparison of the speed of the interpreter 
with the JIT. The results (as you know) are impressive, but you can't 
realistically expect Eliot to do the work for something he considers 
directly detrimental to the goals of Cog. If you suspect that there's no 
difference, it's up to you to prove that, not up to Eliot to disprove 
you. And unless you can show differently, his claim stands unabated.

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

You don't. But why must Eliot jump every time you have a hunch that 
something can be done differently? Adding unneeded generality to a JIT 
just to disprove your hunches is an amazingly pointless waste of time 
for him. Unless you are intending to pay him for it, of course. Oh, you 
weren't...

Cheers,
   - Andreas

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