Hi all,


reg. fastutil: I did a few tests with splitter and mkgmap using the 6.5.15 and the 7.0.11 version,

found no change in output (which is good) but also no significant change in memory usage or

run time, although the changelog for 6.6.0 mentions "significant improvements" .

Maybe the reason is that we already use custom classes for all collections which are critical,

maybe one has to change the source to see these improvements.


The changelog states that some old-standing bugs were fixed. I did not find any place in the sources of splitter or

mkgmap which uses the bogus routines.


So, in short, there is no strong need to move to 7.0.11 now.

The advantage would be that we are "up to date" ,

the disadvantage is a possible trouble for users when they mix old and new jars, which happens

often when you compare the result of an older mkgmap version

with that of the current version.

 

My conclusion:

Let's stay with the old fastuitl libs.


Gerd


Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com>
Gesendet: Mittwoch, 3. August 2016 07:47:44
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Move to Java 1.8
 

Hi Uli + Steve,


reg. config files: I think the file .classpath should also be changed to state 1-8, see attached patch.


Gerd

Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von UliBaer <ulibaer@gmail.com>
Gesendet: Dienstag, 2. August 2016 18:11:34
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Move to Java 1.8
 
Gerd Petermann wrote
> Hi Uli,
>
> thanks for the patch. I tried it and found no significant change in run
> time
> or memory usage.
> My test case: Compile 9 tiles (a part of the Britisch Isles) (with
> --max-jobs on 4 cores)
> In what scenario do you think that the stream methods should save time?
>
> My understanding is that the list streaming is better as it allows
> automatic
> use of multiple cores, so I'd expect improvements in e.g. the gmapsupp
> builder
> which uses a single thread, but not in the code which compiles the tiles.
> On the other hand, the combiners which run single threaded are probably
> more I/O bound.
>
> Gerd

Hi Gerd,

the patch only used the sequential .stream(). method. If you want to use
multiple cores, simply replace the .stream(). with .parallelStream(). and
the jvm tries to work parallel pipelines with multiple threads. You only
have to be aware, that the order of processing is completely arbitrary in
that case, so the atomic operations have to be independent of each other and
not depend on the order of execution. Also the order of elements in the
resulting list is arbitrary. This can be worked around by using a SortedList
for the collection or by using .sorted((o1, o2) ->
o1.getField().compareTo(o2.getField())). near the end of the streaming
pipeline.

Best regards, Uli



--
View this message in context: http://gis.19327.n5.nabble.com/Move-to-Java-1-8-tp5879546p5879702.html
gis.19327.n5.nabble.com
Move to Java 1.8. Hi all, Java 1.7 is no longer maintained, so I guess that most users are already using Java 1.8 I'd like to change the build of splitter and mkgmap to use 1.8 instead of 1.7...

Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev