Having decided that life.pasm was not going to get much better (58 seconds for 5000 generations vs 118 for CVS), I have been looking at other areas for improvements. Arrays seem to be one such area, as the current CVS code expands arrays by creating a new one and copying all the data. I believe Leo is planning to change array.pmc to use the intlist-style code; grey uses a similar but independently designed method, with reasonably encouraging results.
Test program: new P0, .PerlArray set I0, 1 set I1, 0 loop: set P0, I0 set P0[I1], I0 inc I0 inc I1 lt I0, 100000, loop print I0 print "\n" end On my machine, CVS parrot completes the above in an elapsed time of 13 minutes; grey takes 14 seconds. Changing the iteration count to 25000 takes 1 second with grey versus 46 seconds for CVS. This is using a singly linked list of variable sized chunks, without a separate index array. Each chunk is created with a minimum size (4 entries at present), then doubled in size until a maximum size (1024) is reached; further expansion creates a new chunk. In addition, the mark_used function in dod has been changed to not add PMCs to the next_for_GC list if they do not need further processing (i.e. none of the is_PMC_ptr, is_buffer_ptr or custom_mark flags is set) - this has no impact on the array itself, but stops the PerlInts contained within the array from being processed. Finally, the number of used PMCs within each arena is counted during the marking phase, and arenas with used = allocated are skipped during the free phase; this makes a significant difference in the test program, as nothing is ever freed; real world programs will probably not achieve the same benefit, but the cost is low, so it seemed worth while. Incidentally, while testing the latest version of grey I encountered a problem due to intlist's chunk_list, which is a second buffer header embedded within a bufferlike header. The problem was resolved easily enough when found, but I suspect that Leo's Lea allocator code may also have a problem with this - since memory is only freed when the header is freed, and such embedded headers are not known to the dod system, memory allocated to these embedded headers would stick around forever?? -- Peter Gibbs EmKel Systems
