[OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
Laurent Bourgès
bourges.laurent at gmail.com
Thu Apr 11 13:07:59 UTC 2013
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.graham at 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.
>>>>
>>>>
>>>>
>>
>>
More information about the core-libs-dev
mailing list