Walking Randomly

Ever wondered how fast the fastest computer on Earth is? Well wonder no more because the latest edition of the Top 500 supercomputers was published earlier this week. Thanks to this list we can see that the fastest (publicly announced) computer in the world is currently an American system called Jaguar. Jaguar currently consists of 37,376 six-core AMD Istanbul processors and has a speed of 1.75 petaflops as measured by the Linpack benchmarks. According to the BBC, a computation that takes Jaguar a day would keep a standard desktop PC busy for 100 years. Whichever way you look at it, Jaguar is a seriously quick piece of kit.

All this got me thinking….how fast is my mobile phone compared to these computational behemoths?

The key to answering this question lies with the Linpack benchmarks developed by Jack Dongarra back in 1979.  Wikipedia explains:

‘they [The Linpack benchmarks] measure how fast a computer solves a dense N by N system of linear equations Ax = b, which is a common task in engineering. The solution is obtained by Gaussian elimination with partial pivoting, with 2/3·N3 + 2·N2 floating point operations. The result is reported in millions of floating point operations per second (MFLOP/s).’

People have been using the Linpack benchmarks to measure the speed of computers for decades and so we can use the historical results to see just how far computers have come over the last thirty years or so.  Back in 1979, for example, the fastest computer on the block according to the N=100 Linpack benchmark was the Cray 1 supercomputer which had a measured speed of 3.4 Mflop/s per processor.

More recently, a Java version of the Linpack benchmark was developed and this was used by GreeneComputing to produce an Android version of the benchmark.

I installed the benchmark onto my trusty T-Mobile G2 (a rebadged HTC Hero, currently running Android 1.5) and on firing it up discovered that it tops out at around 2.3 Mflop/s which makes it around 66% as fast as a single processor on a 1979 Cray 1 supercomputer.  OK, so maybe that’s not particularly impressive but the very latest crop of Android phones are a different matter entirely.

According to the current Top 10 Android Linpack results, a tweaked Motorola Droid is capable of scoring 52 Mflop/s which is over 15 times faster than the 1979 Cray 1 CPU.  Put another way, if you transported that mobile phone back to 1987 then it would be on par with the processors in one of the fastest computers in the world of the time, the ETA 10-E, and they had to be cooled by liquid nitrogen.

Like all benchmarks, however, you need to take this one with a pinch of salt.  As explained on the Java Linpack page ‘This [the Java version of the] test is more a reflection of the state of the Java systems than of the floating point performance of the underlying processors.’ In other words, the underlying processors of our mobile phones are probably faster than these Java based tests imply.

A friend of mine got me interested in JavaFX recently and my interest grew when I discovered that it had some nice charting functionality.  Dean Iverson has written some great tutorials on the subject over at his blog and includes a link to a demo showing some of the different plot types that are available.

The demo is called ChartDemo and can be found here

http://pleasingsoftware.blogspot.com/2009/06/this-is-test.html

In an ideal world you simply have to click on the demo’s screenshot for it to download and launch but that wasn’t what happened for me.  What happened when I clicked on it was nothing.  No error messages…just nothing.  It’s difficult to google ‘nothing happened’ and get something useful so I downloaded the demo (which had the filename ChartDemo.jnlp) and tried to launch it from the command line using

javaws ChartDemo.jnlp

This gave me the error message

netx: Unexpected net.sourceforge.jnlp.ParseException: Invalid XML document syntax. at
net.sourceforge.jnlp.Parser.getRootNode(Parser.java:1200)

What follows is the story of how I eventually got this demo to work in the hope that it will help someone out there.

So, first things first, what are some of the relevant system specs I am using?  Well, I am running 32bit Ubuntu Linux 9.10 (Karmic Koala) and

java -version

gives

java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)
OpenJDK Server VM (build 14.0-b16, mixed mode)

Now, when I googled the error message I discovered that Linux (more specifically, I guess, the OpenJDK) is much more sensitive to xml errors than Windows/Mac OS X (.jnlp files are written in xml).  Take double quotes for example; according to the W3C XML recommendations you should not use \” inside an xml attribute but should use “"” instead.  Some java implementations don’t seem to care but, at the time of writing at least, OpenJDK definitely does.  Follow this link to see the original discussion thread where I learned this.

The practical upshot of this extra level of strictness is that .jnlp files that work just fine on Windows and Mac OS X won’t work on Linux and I guessed that was what as happening here.  Sadly there were no examples of \” in ChartDemo.jnlp for me to change to “"” so there must be something else ‘wrong’ with it; but what?

I decided to try the ‘stare at it until you figure it out’ approach to debugging and left the laptop on the side of the sofa while watching a movie on TV.   About halfway through the movie, inspiration struck and I changed the line

<update check="background">

to

<update check="background"/>

which got things past the xml parsing stage. Sadly, I then hit another problem. Rather than a working ChartDemo, my efforts were rewarded with nothing more than just a blank window and a load of java errors in the terminal. When I say ‘a load’ I mean HUNDREDS and none of them looked particularly illuminating. I was starting to remember why I had avoided Java in the past but was not about to give up so easily.

Let’s take stock:

• The .nlbp file was fine (or at least didn’t return any parse errors)
• The ChartDemo code must be bug free because if it wasn’t then the author would have been told so rather quickly in the comments section of his blog
• My Java setup was presumably fine since I was able to run other JavaFX examples. For example I successfully worked through a JavaFX programming tutorial on Sun’s website without incident.

Of those three points I figured that the third one was the most likely to be wrong. It was OpenJDK’s handling of the .jnlp file that caused my first problem so maybe it was causing this second problem too. Could I switch from using OpenJDK to a different version of Java I wondered? Some googling ensued and I discovered some useful incantations.

I can list the versions of Java installed on my machine with the command

sudo update-java-alternatives -l

to get

java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-6-sun 63 /usr/lib/jvm/java-6-sun

I can change from the openjdk to sun-java with

sudo update-java-alternatives -s java-6-sun

Once I did this I tried to run the ChartDemo.nlbp file again:

javaws ChartDemo.jnlp

and it worked perfectly. I was rewarded with a very nice demo of JavaFX’s charting functionality and Dean’s tutorials proved to be very useful to me. So useful in fact that I bought his book.

Incidentially, the java-6-sun version of java doesn’t care about the syntax of the .jnlp file quite so much as openjdk. However, if you want to change back to using openjdk you can do

sudo update-java-alternatives -s java-6-openjdk

I hope this little tale helps someone out there. Let me know if it does and also feel free to let me know if I have got anything wrong. My knowledge of all things Java is rather basic at the moment to say the least – something I am trying to change.

At some point in the future I am going to need to do some Java programing for work-related purposes and so I thought I should set up my Ubuntu based laptop for Java development. Everything you need to do this are in the Ubuntu repositories so the installation went without incident but I hit a brick wall when I tried to compile and run this very simple program

class myfirstjavaprog
{
   public static void main(String args[])
   {
      System.out.println("Hello World");
   }
}

I compiled this with the command

javac myfirstjavaprog.java

The .class file was produced without any problems but when I tried to run it with

java myfirstjavaprog

I got a hideous looking error message that started off like this

exception in thread “main” java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

All that for a Hello World program! This was not a good start but it turns out that there is an easy fix. The version of Java being used by my java command was different from that being used by my javac command and they need to be the same. The commands that allow you to configure Java versions on Ubuntu are

sudo update-alternatives –config java

sudo update-alternatives –config javac

Ensure that they are set to use the same version and you should be good to go.