On 10/16/12 12:55 AM, James Wettenhall wrote: > There are 3 new columns for each of "rfbsessions" and > "rfbsession.turbo.hiqual".
Do you mean that you benchmarked the un-encoded RFB sessions? No harm done, but my e-mail didn't call for doing that. I mentioned the un-encoded sessions only in the context of how to re-create the encoded sessions, if anyone reading the list wanted to do so for their own purposes (such as to test different JPEG quality levels, or to encode sessions without JPEG, etc.) > In each case, I ran the X11 benchmarking test only once, but I ran the > Java benchmarking test twice - once using the original > "vncviewerbench.java" script, and once using a modified version of the > script, where I added "-Djava.library.path=/Applications/TurboVNC\ > Viewer\ \(Java\).app/Contents/Resources/TurboJPEG/" to the Java command > to avoid this error: TightDecoder: Class not found: Could not > initialize class org.libjpegturbo.turbojpeg.TJDecompressor. That was my oversight. The script refers to /opt/TurboVNC/java/VncViewer.jar, which is the version of the Java viewer that is (temporarily) packaged alongside the X11 viewer. That version is intended to be used with the libjpeg-turbo SDK, which provides the necessary JNI library under /usr/lib, but what you did above should have the same effect. > I used a MacBook Pro laptop, connected to an external DELL U2312HM > Display (with the laptop closed), and was running in 1920x1080 resolution. > > Here's some info about my laptop: > > *MacBook Pro* > 15-inch, Late 2011 > > *Processor:* 2.5 GHz Intel Core i7 > *Memory:* 8 GB 1333 MHz DDR3 > *Graphics:* AMD Radeon HD 6770M 1024 MB > *Software:* Mac OS X Lion 10.7.5 (11G63) Your results are actually better on the Java front than mine. On your machine, the decoder is only 10% slower with Java vs. native, and blitting is more than 3x as fast, so the aggregate works out to about a 72% speedup under Java. There are some of the 2D datasets that turn in a slower aggregate performance, because of the phenomenon I cited earlier (a bunch of framebuffer updates that involve two tiny rectangles located some distance apart, and the viewer redraws the bounding box of both rectangles rather than the individual rectangles.) I am convinced enough that the Java viewer, at minimum, does no harm on Mac relative to the X11 viewer and that it may in fact prove to be somewhat faster on some workloads. I need to do some more high-level benchmarks as a sanity check, but at the moment, I see no reason not to proceed with the previous plan of re-packaging things on Mac such that TurboVNC.pkg installs the Java viewer rather than the X11 viewer. I also still intend to do a head-to-head shootout with the TigerVNC native viewer. Since, performance-wise, I designed the decoder in that viewer to behave as much like TurboVNC as possible, since the blitter behaves more like our Java viewer, and since it isn't subject to the performance limitations of XQuartz, it will be more of an apples-to-apples comparison and give us a sense of what is possible on that platform, performance-wise. Thanks for your time to provide this data! ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
