Re: Java2d Benchmarking
Christian Thalinger wrote: Which VM was that? Could you do that timings with different VMs? I'd be interested... TWISTI This was on JamVM with latest the classpath head. From an earlier benchmark, native code with GCJ didn't show much of a performance boost (but then again, it wasn't with the latest head). Cacao won't build on my machine (x86_64), but I might give it a try on my home machine. Will be out of town this coming week, though. Francis
Re: Java2d Benchmarking
On Sun, 2006-07-02 at 16:34 -0400, Francis Kung wrote: This was on JamVM with latest the classpath head. From an earlier benchmark, native code with GCJ didn't show much of a performance boost (but then again, it wasn't with the latest head). Cacao won't build on my machine (x86_64), but I might give it a try on my home machine. Will be out of town this coming week, though. Why does it not build? My machine is a x86_64 one too. /me supects binutils-dev again. Grrr... TWISTI
Re: Java2d Benchmarking
On Fri, 2006-06-30 at 16:16 -0400, Francis Kung wrote: To finish off this topic, I've also created a benchmarker in native code using a GTK widget - with some interesting results. I've included the detailed results below, but it seems that JNI overhead is doubling the times for simple java2d operations. Which VM was that? Could you do that timings with different VMs? I'd be interested... TWISTI
Re: Java2d Benchmarking
To finish off this topic, I've also created a benchmarker in native code using a GTK widget - with some interesting results. I've included the detailed results below, but it seems that JNI overhead is doubling the times for simple java2d operations. I tested arcs, cubic curves, lines, and rectangles. Ellipses are special cases of arcs, and quadratic curves of cubic curves, so I skipped those. _Arc_ Native: 478 Classpath: 586 Ratio: 0.82 _Cubic curve_ Native: 612 Classpath: 1105 Ratio: 0.55 _Line_ Native: 108 Classpath: 247 Ratio: 0.44 _Rectangle_ Native: 120 Classpath: 364 Ratio: 0.33 _Arc - Fill_ Native: 314 Classpath: 638 Ratio: 0.49 _Rectangle - Fill_ Native: 10 Classpath: 24 Ratio: 0.42 Francis
Re: Java2d Benchmarking results
It seems like something like this may be relatively simple to try with our gtk port as well. Enumerate each native method and, instead of calling the native methods directly, simply write the function enumeration and parameter values to a queue of sorts. The native command processor would be pretty simple to write. I think it would be simple at a first look, however to write a good performing implementation (which is the goal of all this imho) is another story. Just choosing a NIO-Buffer which does not need to do any conversation oif the platform has the needed endianess brought a large performance boost to Sun's implementation. However sounds pretty interresting ... lg Clemens
Re: Java2d Benchmarking results
Hi folks, Am Montag, den 26.06.2006, 16:50 -0400 schrieb Francis Kung: Further to this thread, I've tested each image operation against the baseline case, and posted the results at http://fkung.wordpress.com/ Interesting! All operations on fill(Rectangle2D) also seem very expensive compared to the rest. I suppose this (at least partially) comes from the JNI overhead here: we transfer the Shape to the native code making 1 JNI call per point/control-point and a couple more to actually paint it. This is very ineffcient, given that (plain) polygon/shape filling is a rather cheap operation. I currently start working on a GL based Graphics2D impl, on top of Escher, which (afaics) has the potential to be very efficient, simply because it avoids JNI calls altogether (except to java.net code every now and then). This could be even more efficient than Sun does (they push 'graphics commands' to a queue, which is read by a native thread that translates it to native GL calls, which - in the case of X - are pushing commands to a queue again... if I understand that correctly). Cheers, Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Java2d Benchmarking results
Further to this thread, I've tested each image operation against the baseline case, and posted the results at http://fkung.wordpress.com/ The results: classpath unquestionably falls behind on the baseline test (no double-buffer, anti-aliasing off, no special options), but definitely holds its own in image-processing options. Anti-aliasing, for example, takes up to 100x longer on Sun, but requires almost no extra time on Classpath. Transparency and custom stroking also stand out. Our main weaknesses, apart from the slow baseline in the first place, come mostly in image-processing: rotating and shearing GIF/PNG files. All operations on fill(Rectangle2D) also seem very expensive compared to the rest. Some other things to keep in mind: - our handling of transparent PNG's is buggy, ie, we still render the entire image opaque - composite/transparent draws are buggy: we fill the shape instead of drawing it - Classpath's non-anti-aliased shapes look better than Sun's Cheers, Francis On Fri, 2006-06-23 at 17:49 -0400, Francis Kung wrote: On Wed, 2006-06-21 at 14:59 +0200, Sven de Marothy wrote: Did you take into account the fact that Sun's impl defaults to antialiasing turned off (on Linux) wheras Classpath defaults to having antialiasing on? I imagine that can have an effect, too. With the latest patch just committed, many such options can now be explicitly set and tested. Anti-alias results are very interesting - as Roman said, the benchmark difference on Classpath is minimal (~15%), whereas Sun has a huge difference (in the area of 8x longer to anti-alias, tested on ellipses). In fact, with anti-alias turned on, Classpath is significantly faster, up to 50%! I'll do a more detailed comparison next week, but it seems we make some nice gains for some of the options, and fall behind horribly with others. Gives us a starting point for looking at optimization. Francis
Re: Java2d Benchmarking results
On Wed, 2006-06-21 at 14:59 +0200, Sven de Marothy wrote: Did you take into account the fact that Sun's impl defaults to antialiasing turned off (on Linux) wheras Classpath defaults to having antialiasing on? I imagine that can have an effect, too. With the latest patch just committed, many such options can now be explicitly set and tested. Anti-alias results are very interesting - as Roman said, the benchmark difference on Classpath is minimal (~15%), whereas Sun has a huge difference (in the area of 8x longer to anti-alias, tested on ellipses). In fact, with anti-alias turned on, Classpath is significantly faster, up to 50%! I'll do a more detailed comparison next week, but it seems we make some nice gains for some of the options, and fall behind horribly with others. Gives us a starting point for looking at optimization. Francis
Re: Java2d Benchmarking results
On Tue, Jun 20, 2006 at 04:40:25PM -0400, Francis Kung wrote: Hi, I've run the java2d benchmarker in a few configurations, with the results as follows. Natively compiling the code doesn't yield much of an improvement over jamVM. Some interesting results. How can I run the benchmarks? I'd like to run it with CACAO. TWISTI
Re: Java2d Benchmarking results
On Tue, 2006-06-20 at 16:40 -0400, Francis Kung wrote: Hi, I've run the java2d benchmarker in a few configurations, with the results as follows. Natively compiling the code doesn't yield much of an improvement over jamVM. Some interesting results. Did you take into account the fact that Sun's impl defaults to antialiasing turned off (on Linux) wheras Classpath defaults to having antialiasing on? I imagine that can have an effect, too. /Sven
Re: Java2d Benchmarking results
Hi Sven, I've run the java2d benchmarker in a few configurations, with the results as follows. Natively compiling the code doesn't yield much of an improvement over jamVM. Some interesting results. Did you take into account the fact that Sun's impl defaults to antialiasing turned off (on Linux) wheras Classpath defaults to having antialiasing on? I imagine that can have an effect, too. I implemented the AA switch for CairoGraphics2D and was quite surprised that turning off AA in Cairo doesn't make things much faster. Only uglier ;-) /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Java2d Benchmarking results
Hi Christian, Roman, How can I run the benchmarks? I'd like to run it with CACAO. From your classpath directory (/usr/local/classpath/share/classpath by default) you can invoke it using cacao gnu.classpath.examples.java2d.J2dBenchmarkGUI Yeah sure, most of the work is done in native code, so it doesn't really matter if the VM is an interpreter, completely compiled or jit. I was talking to fitzsim yesterday, and we also figured that it was down to Cairo. I spent a bit of time trying to install cairo with glitz, to see what the improvement would be, but had no luck. Francis
Re: Java2d Benchmarking results
On Wed, 2006-06-21 at 10:59 +0200, Roman Kennke wrote: Natively compiling the code doesn't yield much of an improvement over jamVM. Some interesting results. Yeah sure, most of the work is done in native code, so it doesn't really matter if the VM is an interpreter, completely compiled or jit. I believe Sun's OpenGL backend avoids JNI overhead by writing GUI commands to a queue in some kind of bytecode, and then having a single native thread pulling the commands off the queue in a loop to call the underlying toolkit routines. My understanding is that this worked so well that they plan on doing the same thing for their other peer ports. It seems like something like this may be relatively simple to try with our gtk port as well. Enumerate each native method and, instead of calling the native methods directly, simply write the function enumeration and parameter values to a queue of sorts. The native command processor would be pretty simple to write. Could any of these benchmarks be tested by converting only a handful of native methods to this alternative implementation? AG
Re: Java2d Benchmarking results
Hi Anthony, Am Mittwoch, den 21.06.2006, 07:19 -0700 schrieb Anthony Green: On Wed, 2006-06-21 at 10:59 +0200, Roman Kennke wrote: Natively compiling the code doesn't yield much of an improvement over jamVM. Some interesting results. Yeah sure, most of the work is done in native code, so it doesn't really matter if the VM is an interpreter, completely compiled or jit. I believe Sun's OpenGL backend avoids JNI overhead by writing GUI commands to a queue in some kind of bytecode, and then having a single native thread pulling the commands off the queue in a loop to call the underlying toolkit routines. My understanding is that this worked so well that they plan on doing the same thing for their other peer ports. Funny, I was thinking up something similar for our Cairo stuff without ever hearing from Sun's impl, since pushing complicated polygons to Cairo takes one JNI call per point plus a couple more for the actual drawing command. I think writing commands to a queue would give a nice boost. Let's try it soon! /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Java2d Benchmarking results
On Wed, 2006-06-21 at 17:15 +0200, Roman Kennke wrote: Funny, I was thinking up something similar for our Cairo stuff without ever hearing from Sun's impl, since pushing complicated polygons to Cairo takes one JNI call per point plus a couple more for the actual drawing command. I think writing commands to a queue would give a nice boost. Let's try it soon! Details here: http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html http://weblogs.java.net/blog/campbell/archive/2005/07/strcrazier_perf.html AG
Re: Java2d Benchmarking results
Francis Kung wrote: Hi Christian, Roman, How can I run the benchmarks? I'd like to run it with CACAO. From your classpath directory (/usr/local/classpath/share/classpath by default) you can invoke it using cacao gnu.classpath.examples.java2d.J2dBenchmarkGUI Yeah sure, most of the work is done in native code, so it doesn't really matter if the VM is an interpreter, completely compiled or jit. I was talking to fitzsim yesterday, and we also figured that it was down to Cairo. I spent a bit of time trying to install cairo with glitz, to see what the improvement would be, but had no luck. I talked with Carl Worth about this yesterday. To test this, we'd need a Graphics that could draw to a GL surface, and we'd need to build Cairo and glitz from source. A GLGraphics may be something we need in the future, but for now the released versions of Cairo do not have glitz support and won't until glitz commits to a stable API, which hasn't happened yet. Even so, I think our graphics backend should be much faster without us needing to draw directly to a GL surface. It may be worthwhile to write a Cairo benchmark that performs the same operations as J2dBenchmark to see how far off our Java implementation is from the theoretical best native implementation. Such a benchmark would also allow us to test fastpath optimizations easily. We'd need a set of benchmarks for each of the Cairo surfaces we draw to. Tom
Re: Java2d Benchmarking results
Francis Kung wrote: Hi, I've run the java2d benchmarker in a few configurations, with the results as follows. Natively compiling the code doesn't yield much of an improvement over jamVM. Some interesting results. Thanks for posting this info. I made a quick chart of the data: http://www.object-refinery.com/classpath/benchmark2d.png Regards, Dave
