Mark Burton <[email protected]> writes: >> Is the default for your patch to not become parallel? It seems that >> making mkgmap parallel is hard, and my personal utility function places >> correct behavior very high and speed not that much. Until the code is >> really shaken out, I don't want to run parallel. I don't know what >> others think, but just a thought. > > At this time, it defaults to creating as many threads as there are > cores. I don't have a big issue with making the default number of > threads = 1 if that's what people want. > > 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.
pgplB3mJw5f6P.pgp
Description: PGP signature
_______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
