Dan Sugalski wrote: > How much of the speed win is from the cycle count instead of stack > walking? Unless you've solved the problem of recursive interpreter > calls and setjmp, it's not a valid solution, no matter what the speed > win might be. According to my notes the progression (for 5000 lives) was: CVS: 172 seconds Cycle count instead of stack walk: 97 seconds COW with stack walk: 158 seconds Cycle count + COW: 81 seconds The performance gain from COW is fairly small, as it really only results from the decreased number of compaction runs needed. The performance loss from the stack walking code is the major area; what concerns me is that that overhead is going to be incurred all the time, not only when situations arise that might require it - you may recall that your original objection to the cycle count code was based on the same reasoning.
Anyway, as I said, this is purely an academic exercise - I am not proposing that any changes be made to Parrot. When features are added to Parrot that cause my current code to fail, I can find an alternative solution, reject those features, or simply abandon the exercise - you do not have those options, so you have to use code that will support everything you intend to do in the future. > Neither 3 nor 4 fundamentally require 1 or 2, I know that Mike is working on implementing COW in a way that will not break anything else; I have just been experimenting with a different approach that is based on point 2. I will be sending my patch to Mike so he can see if there is anything he can use. -- Peter Gibbs EmKel Systems
