<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Need for speed</title>
	<atom:link href="http://kennke.org/blog/2007/01/02/need-for-speed/feed/" rel="self" type="application/rss+xml" />
	<link>http://kennke.org/blog/2007/01/02/need-for-speed/</link>
	<description>Roman Kennke's ramblings</description>
	<pubDate>Wed, 07 Jan 2009 04:54:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Dmitri Trembovetski</title>
		<link>http://kennke.org/blog/2007/01/02/need-for-speed/#comment-3396</link>
		<dc:creator>Dmitri Trembovetski</dc:creator>
		<pubDate>Fri, 05 Jan 2007 19:14:01 +0000</pubDate>
		<guid isPermaLink="false">http://kennke.org/blog/2007/01/02/need-for-speed/#comment-3396</guid>
		<description>&#62; it seems that the result of my own little benchmark varies greatly from machine to machine. 

Actually, that should be expected - different machines may be different hardware, drivers, etc.
What should be constant (or near constant) is the results from repeated runs on the same system.

We do our measurements on machines with minimal activity, no users logged in, networking disabled, 
etc, and still get some variation =(

Also, if you just time a 1000 iterations of some operation and it only
takes say ~50ms - it's too close to the error threshold (and timer resolution on some systems) -
so the results would vary greatly from run to run.

I really wish we had J2DBench open sourced - that way we can all use the same tool!
Oh well, it will be soon.

Thanks,
  Dmitri</description>
		<content:encoded><![CDATA[<p>&gt; it seems that the result of my own little benchmark varies greatly from machine to machine. </p>
<p>Actually, that should be expected - different machines may be different hardware, drivers, etc.<br />
What should be constant (or near constant) is the results from repeated runs on the same system.</p>
<p>We do our measurements on machines with minimal activity, no users logged in, networking disabled,<br />
etc, and still get some variation =(</p>
<p>Also, if you just time a 1000 iterations of some operation and it only<br />
takes say ~50ms - it&#8217;s too close to the error threshold (and timer resolution on some systems) -<br />
so the results would vary greatly from run to run.</p>
<p>I really wish we had J2DBench open sourced - that way we can all use the same tool!<br />
Oh well, it will be soon.</p>
<p>Thanks,<br />
  Dmitri</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: roman</title>
		<link>http://kennke.org/blog/2007/01/02/need-for-speed/#comment-3391</link>
		<dc:creator>roman</dc:creator>
		<pubDate>Fri, 05 Jan 2007 12:18:51 +0000</pubDate>
		<guid isPermaLink="false">http://kennke.org/blog/2007/01/02/need-for-speed/#comment-3391</guid>
		<description>Hi Dmitri,

In the meantime I also noticed that my benchmark is bad. In GNU Classpath we also have a set of Java2D benchmarks which shows better and more fair results:

http://kennke.org/blog/2007/01/03/a-better-comparison/

It seems that the result of my own little benchmark varies greatly from machine to machine. Which isn't the case for the 'real' benchmarks.</description>
		<content:encoded><![CDATA[<p>Hi Dmitri,</p>
<p>In the meantime I also noticed that my benchmark is bad. In GNU Classpath we also have a set of Java2D benchmarks which shows better and more fair results:</p>
<p><a href="http://kennke.org/blog/2007/01/03/a-better-comparison/" rel="nofollow">http://kennke.org/blog/2007/01/03/a-better-comparison/</a></p>
<p>It seems that the result of my own little benchmark varies greatly from machine to machine. Which isn&#8217;t the case for the &#8216;real&#8217; benchmarks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitri Trembovetski</title>
		<link>http://kennke.org/blog/2007/01/02/need-for-speed/#comment-3379</link>
		<dc:creator>Dmitri Trembovetski</dc:creator>
		<pubDate>Fri, 05 Jan 2007 02:41:34 +0000</pubDate>
		<guid isPermaLink="false">http://kennke.org/blog/2007/01/02/need-for-speed/#comment-3379</guid>
		<description>Hello,

What kind of machine you're running this on? 750ms seems to be way too high - I get around 80ms on my rather old SunBlade 2000 (that's on solaris-sparc, so a little hard to compare, I guess - it also depends on the X server). 

Anyway, we have improved the quality of our non-AA shape renderer in jdk6.
I don't, however, see the performance drop you're measuring - it's actually
a little faster on jdk6.


Another thing: your test isn't really correct. Since you're rendering to the screen, all you do
is ask Java2D to issue rendering commands to the X server, which are then buffered by the
server until the queue is full.

If you want to measure the real rendering time, you'll need to flush the queue by 
calling Toolkit.sync() (which would cause XFlush() to be called, forcing the
X server to flush the request queue and complete the rendering).

Regarding the benchmarking - we have a good Java2D benchmark, which is unfortunately still
not open sourced (you can get a hold of it if you agree to the JRL license on jdk7.dev.java.net, it's in j2se/src/share/demo/java2d/J2DBench) - it's a very comprehensive set of Java2D benchmarks
(including different rendering destinations - BufferedImage, Screen, VolatileImage, etc).
You can also take a look at the way the rendering performance should be measured - 
we basically measure how many iterations can be performed within a certain amount of time,
and then time that number of iterations (giving the hotspot some time to warm up first)

Thanks,
  Dmitri
Java2D Team</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>What kind of machine you&#8217;re running this on? 750ms seems to be way too high - I get around 80ms on my rather old SunBlade 2000 (that&#8217;s on solaris-sparc, so a little hard to compare, I guess - it also depends on the X server). </p>
<p>Anyway, we have improved the quality of our non-AA shape renderer in jdk6.<br />
I don&#8217;t, however, see the performance drop you&#8217;re measuring - it&#8217;s actually<br />
a little faster on jdk6.</p>
<p>Another thing: your test isn&#8217;t really correct. Since you&#8217;re rendering to the screen, all you do<br />
is ask Java2D to issue rendering commands to the X server, which are then buffered by the<br />
server until the queue is full.</p>
<p>If you want to measure the real rendering time, you&#8217;ll need to flush the queue by<br />
calling Toolkit.sync() (which would cause XFlush() to be called, forcing the<br />
X server to flush the request queue and complete the rendering).</p>
<p>Regarding the benchmarking - we have a good Java2D benchmark, which is unfortunately still<br />
not open sourced (you can get a hold of it if you agree to the JRL license on jdk7.dev.java.net, it&#8217;s in j2se/src/share/demo/java2d/J2DBench) - it&#8217;s a very comprehensive set of Java2D benchmarks<br />
(including different rendering destinations - BufferedImage, Screen, VolatileImage, etc).<br />
You can also take a look at the way the rendering performance should be measured -<br />
we basically measure how many iterations can be performed within a certain amount of time,<br />
and then time that number of iterations (giving the hotspot some time to warm up first)</p>
<p>Thanks,<br />
  Dmitri<br />
Java2D Team</p>
]]></content:encoded>
	</item>
</channel>
</rss>
