Leopold Toetsch wrote: [ this is Mr. f'up myself again ]
By reducing the amount of DOD runs I now have:$ time parrot -j stress.pbc real 0m0.849s
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real 0m0.708s
But this still could go faster:
$ parrot -j stress.pbc # w/o pmc->synchronize (-10% size)
A total of 9 DOD runs were made
real 0m0.635s
This test is with a 10% smaller PMC giving 10% increase in speed. This seems to indicate again the necessity for a smaller Scalar PMC as already proposed in the thread
"[CVS ci] mark5 - PMC/Buffer unification #10".
Having only 50% size for a "plain" scalar could inidicate 50% speed increase for such programs with many live PMCs.
The problem is, we can't promote a smaller PMC to a bigger one. But what about this strategy:
- scalars start with a small PMC (16 bytes on a 32 bit machine)
except when the HL indicates, that the var needs properties or may be
be shared between threads
- 99% of all scalars will probably nether be used differently
- when such a small scalar gets runtime properties added then:
- make a new "big" PMC and point the old PMC to the newly created one.
This should work like an unvisible reference, doing all functions on
behalf of the scalar.
- in the next DOD run, when we find such a PMC pointer, replace it with
the real PMC. As this might need a modified pobject_lives function
(digging in all places to find all occurencies) this could be a
separate step too, run only when needed.
leo
