Jim, Andrea, I updated MapBench to provide test statistics (avg, median, stddev, rms, med + stddev, min, max) and CSV output (tab separator): http://jmmc.fr/~bourgesl/share/java2d-pisces/MapBench/
Here are the results (OpenJDK8 Ref vs Patched): http://jmmc.fr/~bourgesl/share/java2d-pisces/ref_det.log http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_det.log test threads ops Tavg Tmed stdDev rms Med+Stddev min max boulder_17 1 20 180,22% 181,08% 1186,01% 181,17% 185,92% 176,35% 170,36% boulder_17 2 20 183,15% 183,80% 162,68% 183,78% 183,17% 174,01% 169,89% boulder_17 4 20 216,62% 218,03% 349,31% 218,87% 226,68% 172,15% 167,54% shp_alllayers_47 1 20 243,90% 244,86% 537,92% 244,87% 246,39% 240,64% 231,00% shp_alllayers_47 2 20 286,42% 287,07% 294,87% 287,07% 287,23% 277,19% 272,23% shp_alllayers_47 4 20 303,08% 302,15% 168,19% 301,90% 295,90% 462,70% 282,41% PATCH: test threads ops Tavg Tmed stdDev rms Med+Stddev min max boulder_17 1 20 110,196 109,244 0,529 109,246 109,773 108,197 129,327 boulder_17 2 40 127,916 127,363 3,899 127,423 131,262 125,262 151,561 boulder_17 4 80 213,085 212,268 14,988 212,796 227,256 155,512 334,407 shp_alllayers_47 1 20 1139,452 1134,858 5,971 1134,873 1140,829 1125,859 1235,746 shp_alllayers_47 2 40 1306,889 1304,598 28,157 1304,902 1332,755 1280,49 1420,351 shp_alllayers_47 4 80 2296,487 2303,81 112,816 2306,57 2416,626 1390,31 2631,455 REF: test threads ops Tavg Tmed stdDev rms Med+Stddev min max boulder_17 1 20 198,591 197,816 6,274 197,916 204,091 190,805 220,319 boulder_17 2 40 234,272 234,09 6,343 234,176 240,433 217,967 257,485 boulder_17 4 80 461,579 462,8 52,354 465,751 515,153 267,712 560,254 shp_alllayers_47 1 20 2779,133 2778,823 32,119 2779,009 2810,943 2709,285 2854,557 shp_alllayers_47 2 40 3743,255 3745,111 83,027 3746,031 3828,138 3549,364 3866,612 shp_alllayers_47 4 80 6960,23 6960,948 189,75 6963,533 7150,698 6432,945 7431,541 Linux 64 server vm JVM: -Xms128m -Xmx128m (low mem) Laurent 2013/4/14 Andrea Aime <andrea.a...@geo-solutions.it> > On Tue, Apr 9, 2013 at 3:02 PM, Laurent Bourgès <bourges.laur...@gmail.com > > wrote: > >> Dear Java2D members, >> >> Could someone review the following webrev concerning Java2D Pisces to >> enhance its performance and reduce its memory footprint (RendererContext >> stored in thread local or concurrent queue): >> http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-1/ >> >> FYI I fixed file headers in this patch and signed my OCA 3 weeks ago. >> >> Remaining work: >> - cleanup (comments ...) >> - statistics to perform auto-tuning >> - cache / memory cleanup (SoftReference ?): use hints or System >> properties to adapt it to use cases >> - another problem: fix clipping performance in Dasher / Stroker for >> segments out of bounds >> >> Could somebody support me ? ie help me working on these tasks or just to >> discuss on Pisces algorithm / implementation ? >> > > Hi, > I would like to express my support for this patch. > Given that micro-benchmarks have already been run, I took the patch for a > spin in a large, real world benchmark instead, > the OSGeo WMS Shootout 2010 benchmark, for which you can see the results > here: > > http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-2010 > > The presentation is long, but suffice it to say all Java based > implementations took quite the beating due to the > poor scalability of Ductus with antialiased rendering of vector data (for > an executive summary just look > at slide 27 and slide 66, where GeoServer, Oracle MapViewer and > Constellation SDI were the > Java based ones) > > I took the same tests and run them again on my machine (different hardware > than the tests, don't try to compare > the absolute values), using Oracle JDK 1.7.0_17, OpenJDK 8 (a checkout a > couple of weeks old) and the > same, but with Laurent's patches applied. > Here are the results, throughput (in maps generated per second) with the > load generator (JMeter) going > up from one client to 64 concurrent clients: > > *Threads* *JDK 1.7.0_17* *OpenJDK 8, vanilla* *OpenJDK 8 + pisces > renderer improvements* *Pisces renderer performance gain, %* 1 13,97 > 12,43 13,03 4,75% 2 22,08 20,60 20,77 0,81% 4 34,36 33,15 33,36 0,62% 8 > 39,39 40,51 41,71 2,96% 16 40,61 44,57 46,98 5,39% 32 41,41 44,73 48,16 > 7,66% 64 37,09 42,19 45,28 7,32% > > Well, first of all, congratulations to the JDK developers, don't know what > changed in JDK 8, but > GeoServer seems to like it quite a bit :-). > That said, Laurent's patch also gives a visible boost, especially when > several concurrent clients are > asking for the maps. > > Mind, as I said, this is no micro-benchmark, it is a real application > loading doing a lot of I/O > (from the operating system file cache), other processing before the data > reaches the rendering > pipeline, and then has to PNG encode the output BufferedImage (PNG > encoding being rather > expensive), so getting this speedup from just a change in the rendering > pipeline is significant. > > Long story short... personally I'd be very happy if this patch was going > to be integrated in Java 8 :-) > > Cheers > Andrea > > -- > == > GeoServer training in Milan, 6th & 7th June 2013! Visit > http://geoserver.geo-solutions.it for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- >
