
On Fri, Nov 25, GerdP wrote:
Hello list,
the current implementation limits the number of threads to the number of available cores. I changed the code to allow +2 threads. This results in a much better throughput on my dual core machine (e.g. germany.osm.pbf is 100 seconds or 17% faster) with r190 + patchv7. What could be the reason for this limit?
Let's say it in this way: In my daily work the experience is, that most of the time the limitating factor is not the number of cores, but the I/O bandwith of your harddisk. While in your example with a dual core machine, the I/O Bandwith should be enough, for some of our machines with a 2 digit number of cores, limitating the number of processes to number of cores/2 or even more makes it much faster. That's why I think the number of threads should be a config option which the user can adjust to his hardwre and not a hard number. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)