On Mon, May 18, 2009 at 07:59:43AM -0400, Greg Troxel wrote:
How about this:
1 - with no option specified, the default number of jobs (aka threads) is 1.
2 - specifying --max-jobs without a value will maximise the number of jobs (i.e. create one thread per core).
3 - specifying --max-jobs=N will create N threads.
Would that suit you?
That sounds great. I think it would be reasonable to change the default to #2 after enough time has passed that we are really sure that there are no problems from running in parallel.
Perhaps there could be a regression test to compare the output from parallel and non-parallel runs. I'm not sure if they are meant to be bit-for-bit identical, or if not if you can articulate the allowable differences. This might require code to parse a .img into canonical form for semantic diffing, but that's probably a useful thing to have anyway.
+1. Adding some regression testing and pretty-printing infrastructure can never hurt. I haven't tested these patches, because my laptop is only 1.5 GiB and dual-core. I'm not sure if two tiles of Finland would fit in the memory at once. Marko