Last idea: I will enhance Andrea's mapBench benchmark to have statistics per threads: number of loops, avg, min, max, stddev;
I guess that the total bench time is not so representative as the thread pool can distribute the work load differently at each test => statistics will help to have better timing / comparison between bench runs. Regards, Laurent 2013/4/11 Laurent Bourgès <bourges.laur...@gmail.com> > Jim and Sergey, > > 1/ Here are few benchmarks (based on mapBench again) running several > modified versions of AAShapePipe: > http://jmmc.fr/~bourgesl/share/AAShapePipe/mapBench/ > - ref: > 1 threads and 20 loops per thread, time: 3742 ms > 2 threads and 20 loops per thread, time: 4756 ms > 4 threads and 20 loops per thread, time: 8528 ms > > 1 threads and 20 loops per thread, time: 56264 ms > 2 threads and 20 loops per thread, time: 75566 ms > 4 threads and 20 loops per thread, time: 141546 ms > > - int4: > 1 threads and 20 loops per thread, time: 3653 ms > 2 threads and 20 loops per thread, time: 4684 ms > 4 threads and 20 loops per thread, time: 8291 ms > > 1 threads and 20 loops per thread, time: 55950 ms > 2 threads and 20 loops per thread, time: 74796 ms > 4 threads and 20 loops per thread, time: 139924 ms > > - byte[]: > 1 threads and 20 loops per thread, time: 3795 ms > 2 threads and 20 loops per thread, time: 4605 ms > 4 threads and 20 loops per thread, time: 8246 ms > > 1 threads and 20 loops per thread, time: 54961 ms > 2 threads and 20 loops per thread, time: 72768 ms > 4 threads and 20 loops per thread, time: 139430 ms > > - int4 / byte[] / rectangle cached in TileState: > 1 threads and 20 loops per thread, time: 3610 ms > 2 threads and 20 loops per thread, time: 4481 ms > 4 threads and 20 loops per thread, time: 8225 ms > > 1 threads and 20 loops per thread, time: 54651 ms > 2 threads and 20 loops per thread, time: 74516 ms > 4 threads and 20 loops per thread, time: 140153 ms > > So you may be right, results are varying depending on the optimizations > (int4, byte or all) ! > Maybe I should test different versions on optimized pisces renderer ... > > Here is an updated patch: > http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-2/ > > > 2/ Thanks for your comments: actually a refactoring is possible to use a > (shared) TileState instance replacing int[] bbox, rectangle bbox): > - RenderingEngine.AATileGenerator getAATileGenerator(... int[] abox) > > it is very interesting here to propose an extensible tile state: maybe > created by the renderer engine to cache other data ? > > - Rectangle and Rectangle2D are only used as the shape s and device > rectangle given to CompositePipe.startSequence(): > public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, > int[] abox); > > Changing this interface may become difficult: > AlphaColorPipe.java: > > 41: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle dev, > OK, [s, dev, abox] unused > > AlphaPaintPipe.java > > 81: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle > devR, > create a paint context: > PaintContext paintContext = > sg.paint.createContext(sg.getDeviceColorModel(), > devR, > s.getBounds2D(), > sg.cloneTransform(), > sg.getRenderingHints()); > > GeneralCompositePipe.java: > > 62: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle > devR, > abox unused and create a paint context: > PaintContext paintContext = > sg.paint.createContext(model, devR, s.getBounds2D(), > sg.cloneTransform(), > hints); > > SpanClipRenderer.java > > 68: public Object startSequence(SunGraphics2D sg, Shape s, Rectangle > devR, > Forward to another composite pipe > return new SCRcontext(ri, outpipe.startSequence(sg, s, devR, abox)); > > It could be possible to use TileState into PaintContext interface / fix > implementations but it may become a tricky change (API change). > > What do you think ? > > Laurent > > > 2013/4/11 Jim Graham <james.gra...@oracle.com> > >> I'm pretty familiar with all of this code and there aren't any places >> that save the tile array that I remember. The embedded code that Pisces >> was taken from had some caching of alpha arrays, but we didn't use or keep >> that when we converted it for use in the JDK... >> >> It occurs to me that since you are collecting the various pieces of >> information into an object to store in the thread local storage, perhaps we >> should convert to a paradigm where an entire Tile Generation sequence uses >> that object "TileState?" as its main way to communicate info around the >> various stages. Thus, you don't really need an int[4] to store the 4 >> parameters, they could be stored directly in the TileState object. This >> would require more sweeping changes to the pipeline, but it might make the >> code a bit more readable (and make the hits to convert over more moot as >> they would be improving readability and give more focus to the >> relationships between all of the various bits of data). Then it simply >> becomes a matter of managing the lifetime and allocation of the TileState >> objects which is a minor update to the newly refactored code. >> >> ...jim >> >> On 4/10/13 3:59 PM, Sergey Bylokhov wrote: >> >> On 4/10/13 11:46 PM, Laurent Bourgčs wrote: >>> >>>> I see that some methods which take it as argument doesn't use them. And >>>>> most of the time we pass AATileGenerator and abox[] to the same >>>>> methods, so >>>>> it could be merged? >>>>> >>>>> For now I did not want to modify the AAShapePipe signatures: abox[] is >>>> filled by AATileGenerator implementations (ductus, pisces, others) in >>>> order >>>> to have the shape bounds and render only tiles covering this area. >>>> >>> You still have to check all the places, where these objects are filled >>> and used, and refactoring is a good start, no? >>> Otherwise, how can you prove that these arrays are used as you would >>> expect, These arrays could be stored like the cache or re-used for other >>> purpose(if someone don't want to create new arrays). >>> Probably it will be good to split all your changes / to a few CR. >>> - cleanup >>> - Some small changes which gave us most speedup >>> - all other things. >>> ?? >>> >>>> >>>> Also I suggest to use jmh for java micrbenchmarks. >>>>> http://openjdk.java.net/****projects/code-tools/jmh<http://openjdk.java.net/**projects/code-tools/jmh> >>>>> <http:/**/openjdk.java.net/projects/**code-tools/jmh<http://openjdk.java.net/projects/code-tools/jmh> >>>>> > >>>>> >>>>> So your test will be: >>>>> http://cr.openjdk.java.net/~****serb/AAShapePipeBenchmark.java<http://cr.openjdk.java.net/%7E**serb/AAShapePipeBenchmark.java> >>>>> **<http://cr.openjdk.java.net/%**7Eserb/AAShapePipeBenchmark.**java<http://cr.openjdk.java.net/%7Eserb/AAShapePipeBenchmark.java> >>>>> > >>>>> >>>>> >>>>> Thanks, >>>> I will try it asap >>>> >>>> Laurent >>>> >>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>>>> >>>>> >>> >>> >
