Saturday, May 16, 2009

JPC: x86 Emulator in Java

Last night, I was reading Caches and Maps in Terracotta by Alex Miller when I came upon his link to the JPC (a.k.a. JavaPC) Project.  It sounded familiar and I decided to follow the link.  It turns out to be an open source project implementing an impressively functional and performant x86 emulator in Java.  I had fun last night launching an MS-DOS environment within an applet (what a concept!) and playing Donkey Kong for the first time in ages.  According to the site, the emulated layer runs at about 20% of your processor's speed - not bad for a emulator written in pure Java.

Note: After my first visit to the site, it seemed to be having problems.  Just in case it had to do with visitor load, I changed the link above to point to the copy in Coral Cache.  The site is now totally back up and behaving normally.  If Coral has any problems or is slow, you can safely go to the site directly.

Update: I got an email from one of the JPC team members saying that they'll be at JavaOne this year with some new stuff.  I wish I could be there to see it.  I guess I'll have to wait for it to show up on their site.

Monday, May 11, 2009

Trying out DISQUS for Comments

I've decided to try out DISQUS for handling comments on my blog. Let me know what you think. I can always revert back to Blogger comments if desired.

Update: It turns out that there's a bug in Blogger that precludes you from using DISQUS in conjunction with an external post editor. Since I'm happy with Windows Live Writer, I guess I'll disable DISQUS for the time being and revisit the decision if the bug gets fixed.

Sunday, May 10, 2009

VisualVM and Cutting Method Calls by Over 1000x

I’ve been using VisualVM on and off with modest success since I first found out about it at JavaOne 2008.  In addition, since JDK 6 update 7, it’s been included as part of the standard JDK installation (released in July of 2008).  I was quite happy when it helped me identify bottlenecks and cut down the time to run a suite of unit tests by 50% (from 2 minutes to 1 minute).  After all, the less time it takes to run unit tests, the more often they’ll get run.  However, my biggest success using VisualVM came in early April, when I was asked to figure out why a use case was exhibiting disturbing performance characteristics.

When I first walked through the use case, it was taking about 10 seconds to run with 50 items.  The time appeared to be proportional to the number of items or perhaps even worse.  This was a scary prospect given that there would often be more than 10,000 items in a real production setting and that the use case was intended to be interactive (as opposed to a batch or background task).  A careful code review might have revealed the problem, but I knew it would be far more efficient to profile the code as a way to identify hot spots.  I started up VisualVM, connected to the relevant JVM, turned on CPU profiling, and collected data for the use case.  Sadly, I seem to have lost the relevant snapshot, so you’ll have to trust me when I tell you that the method SqlQueryFile.isSupported() was being called over 36 million times!  I made some minor tweaks to the method itself which improved its performance by about 10 percent – okay, but not nearly enough.  I next identified what was effectively a loop invariant.  The isSupported() method was being called repeatedly with the same query and schema.  As you can see from the snippets below, I pulled that check out of the nested loop.

Before:
for(Platform platform=p; platform != null; platform=platform.getParent()) {
  for(SqlQuery q : metricQueries) {
    if (isSupported(q, datasourceSchema)) {
      if(q.getMetricPath().equalsIgnoreCase(metricPath) &&
         q.getPlatform().equalsIgnoreCase(platform.getName())) {
        if(ret==null) {
          ret=q;
        } else {
          if(isMoreRecentThan(q, ret)) {
            ret=q;
          }
        }
      }
    }
  }
}
After:
Collection supportedQueries = new ArrayList();
for (SqlQuery q : metricQueries) {
  if (isSupported(q, datasourceSchema) && q.getMetricPath().equalsIgnoreCase(metricPath)) {
    supportedQueries.add(q);
  }
}

// need to optimized this code for better performance
for (Platform platform = p; platform != null; platform = platform.getParent()) {
  for (SqlQuery q : supportedQueries) {
    if (q.getPlatform().equalsIgnoreCase(platform.getName()) &&
        (ret == null || isMoreRecentThan(q, ret))) {
      ret = q;
    }
  }
}

When I ran the profiler again, it turned out I'd vastly reduced the number of calls to (~36 million to ~9 million) and the time spent in (80+% to 26.3%) the isSupported() method, as you can see in the picture below:

snapshot-040109-7pm

I probably could have left it there, but after taking another quick look, I noticed a very simple way to save even more time.  I could flip the order of the conditional expression in the first if statement.  That way, the cheap operation (which usually returns false) would come first and frequently allow us to skip the evaluation of isSupported().

if (q.getMetricPath().equalsIgnoreCase(metricPath) && isSupported(q, datasourceSchema)) {

To my surprise, this cut the number of calls to around 27,000 and the time spent in the method to 1%!

snapshot-040109-8pm

With these optimizations in place, the same use case with 11,000 items now took less than a second.  Thanks VisualVM!

Update: This post was a second place winner in the Java VisualVM Blogging Contest!

Saturday, May 9, 2009

High Performance, Parallel, & Grid Computing

On Wednesday night (May 6th), I attended an alumni event held by the UMass Boston CS Department in the beautiful five year old Campus Center.  It was great to see my professors and former classmates, along with talking with current students about their software engineering projects.  Toward the end of the event, there was a talk given by an alumnus named Richard Anderson, the CTO of Symmetric Computing, a company that makes hardware and OS-level software for High Performance Computing (HPC).  Their slogan is something along the lines of “Supercomputing for the Masses”.  The speaker gave a fairly typical overview of the history of CPU performance, including references to Moore’s Law, hitting the gigahertz wall, and the emergence of multi-core chips, followed by a discussion of parallel programming.  He mentioned several times that the company would be making one of their 48 core/350GB systems available to the university for academic use.  It was a decent talk, if not extremely exciting.  It made me think of concurrent programming, grid/cloud computing, and the cool compute appliances made by Azul Systems.  Based on questions asked by myself and others, I was disappointed to discover that although the technical gap between HPC and the rest of the computing world is narrowing, most of the HPC world seems unaware of this.  A lot of work has gone into making clusters of commodity hardware work together and coding for these architectures easier (think Google, Map/Reduce, etc.).  It would be nice if people in HPC and distributed computing could do a better job of exchanging ideas.  Even if typical clusters have to deal with latency issues and the inability to directly access large amounts of memory, that doesn’t explain why someone should code an HPC app in Fortran or C on a Symmetric box instead of in Java on a 432 core/384GB Azul box.
I realize that this is a bit of a rant.  If any readers can provide counter-arguments or counter-examples, I’d be happy (and reassured) to read and know about them.
Update: I forgot to mention that if you’re doing academic research or teaching a class in clustering/distributed computing, you should check out the fairly new Amazon Web Services in Education program.  They provide free credits to educators, researchers, and students.  Pretty cool!