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