the theraded version is 300-400% faster as the last stable version on a quad core system
the most time give the png optimoze process and the optimited prosess structure only the roma slow down the client now ;) a emty tileset is in 30 sek finsihed and a default tile in ~ 5min? only the threaded upload is current not finieshed in the threaded branch René PS: i work current on a automtic thileinfo generator David Lynch schrieb: > 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. > _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
