On Sat, May 7, 2011 at 4:15 PM, 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
I don't understand that sentence. If I change a class to be non-compact, how it can have worst performance? wouldn't it be faster since you don't pay the indirection? (the if you pay it always).
you said "some classes". Could you give an example?
Thanks for the clarification.
Mariano
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.
Cheers,
- Andreas