On 7 May 2011 16:15, Andreas Raab andreas.raab@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.