[Tilesathome] Threading maplint optimizing?

[David Lynch]

On Wed, Dec 17, 2008 at 22:43, Matthias Julius <lists at julius-net.net> wrote:
> "David Lynch" <djlynch at gmail.com> 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 at 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
djlynch at gmail.com