[OpenJDK Rasterizer] RFR: Marlin renderer #2

[Laurent Bourgès]

Hi Jim,

>> I will now try being more opened minded to your valuable comments to
>> improve code maintainability without sacrifying too much the performance
>> level.
>
> It's a philosophy, not a hard requirement.  And it is more important in a
large project, especially Open Source where you get new people working on
things all the time.
>
> In the short term, with just you working on the code, some concepts are
much more manageable.  Since you seem to be the only one putting forth any
effort right now I have to balance disrupting the practices and
philosophies that you are more comfortable with since they would make you
more productive and the future of what happens when you achieve your
objectives and the code awaits a new champion.  Please don't ever let it
progress to the point where you are too frustrated with some of the
suggestions I am proposing that you want to walk away from the work,
though.  In the long run, having the improvements you are making in the
code will be considerably more important than the amount of up-take time
for future efforts.  On the other hand, I do think that the best code bases
I've seen in the past have been very concise to read and learn and
understand and have had almost no quirky side effects outside of the
advertised APIs.  It's more of a mindset to care about code simplicity as
you care about efficiency so both get designed in as you go.

That seems a good philosophy: I will stay focused on performance and you on
readability / maintainability.

Moreover your java2d experience is very important to me as you have the
global overview on the complete pipelines (native, java fx, AA or not).

As you know the java2d contributors, could you invite / motivate some of
them to join this project ?

I hope our collaboration will be successfull if we manage to stabilize
Marlin code soon (minor algorithmic changes) and push it into jdk9 repo.

Next we could work on RnD = more complex algorithmic improvements ...

Anyway it is very important to release Marlin to JDK users as soon as we
can.

>> If you are now OK, can I push the patch including the 2 syntax fixes ?
>> So I need to create a new bug id (to be able to push the changeset)  ...
>
>
> Definitely.

Ok I will merge, build, test and push it today.

>
>> Should I wait you merge gr repo with latest jdk changes ?

>
> D'oh!  I'll take care of that right away.

Thanks.

>
>> As you wonder  if initial arrays are still necessary, I will run tonight
>> some benchmarks with initial arrays = [0].
>
>
> "arrays = [0]" - is that arrays set to bucket 0 sizes?  That would be my
guess as to how to proceed.

Exactly: I changed MarlinConst.INITIAL_ARRAY... to 0.
So initial arrays were created with size 0 or 1 that forced using array
caches.

I kept marlin statistics that indicate lots of cached arrays with usage
counts.
I will push them on cr.openjdk...

However, I did not modify the OffHeap buffer size storing edge data = 128k.
This edge array is the most critical and I use Unsafe instead of array
cache to store both int/float values.
I am sure it would have a big performance impact if downsized.

I think it explains the difference with my first and last tests: 30% vs 5%.
I will run benchmarks with offheap initial size = 10.

>> I think the 30% overhead was a long time ago and should be less (dirty
>> cache). However the cache code represents some overhead = get/grow/put +
>> more resizing (copy) than initial arrays....
>
>
> I would think that starting out with bucket 0 sizes would reduce the
frequency of resizing, no?

Right. In this test, arrays are growing using bucket sizes.
Bucket 0: size=4096 (16k)
Bucket 1: size=16384 (64k)

I tuned better initial arrays: smaller or larger than 4k = overhead for
smaller arrays and more resizing for larger initial arrays.

PS: I will also run benchmarks with smaller heap = 256mb instead of 2gb. It
will evaluate the GC overhead with/without initial arrays.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20150619/f277ada7/attachment.html>