On Wed, Dec 17, 2008 at 22:43, Matthias Julius <[email protected]> wrote: > "David Lynch" <[email protected]> writes: > >> The question with this is whether there is enough time when less than >> the ideal number of sub-processes are active to make the added >> complexity and memory usage worthwhile. I've been experimenting on my >> system with a change where the largest zoom levels are assigned to the >> first (n-1) children and all remaining zoom levels to the last child. >> On my two-core machine, rendering tiles for z17 takes about as long >> (actually slightly longer) as rendering z12-z16 combined, so there is >> much less time with a core sitting idle than with the stable client's >> method. > > This only helps for two cores. If you try to get the performance of > four cores you are out of luck.
I think it would be a slight improvement on the current scheme for four-core systems, given the way zoom levels are allocated, but it's less of an improvement than on a two-core system and still far from ideal. > I once considered changing the forking to start a new fork for the > rendering of every tileset. The main program would do all the server > communication and start as many render forks as specified in the > config. This would work as follows (with fork=2): > > This would not improve turnaround of jobs but would probably have > better overall throughput than the current forking stuff. And it > should scale a lot better. I honestly haven't looked at what the threading project is doing yet, but my preference would be to optimize for turn around time ahead of overall throughput, since I'm doing a lot of editing of the map data these days and part of the goal of osmarender/t...@h was to provide quick feedback on edits. However, there's enough improvements to be made in both areas that it's probably not worth debating. -- David J. Lynch [email protected] _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
