Clay Lenhart's Blog » Architecture

The “Many Core” Problem

Clay Lenhart — Sat, 25 Oct 2008 23:03:31 +0000

We, as developers, have a problem. CPUs will continue to have more cores, and each core is not going to be any faster. The only way to write faster applications is to write multithreaded code, which has two challenges:

Multithreaded code is complex to write and think about.
Multithreaded code is difficult to test.

From what I’ve seen, people are pursuing 4 approaches.

Better Languages

If languages are the whole answer, the language has to make it impossible to write multithreaded bugs, otherwise you only address the first problem (the complexity).

Erlang is one such language that removes whole class of multithreaded bugs. Erlang’s approach is to isolate the threads, and give them a way to pass messages to each other. However programming in Erlang is awkward and arguably it makes the code more complex.

Other languages, like Clojure and F#, take a different approach and make it easier to write and deal with multithreaded issues, however they don’t prevent you from writing multithreaded bugs. These languages do not address the whole problem as you still need a way to test the code.

Better Libraries

Microsoft has a library for .Net called Parallel Task Library to make it easier to write multithreaded code. Need to operate on each element in an array? Use the Parallel.For() method. This library makes it easier to think and write multithreaded code, but it doesn’t make it any easier to test.

Static Code Analyzer

Java has a static code analyzer that is able to find multithreading bugs called FindBugs. It looks at your code and reports any code that will cause multithreaded bugs. This would address the second issue, because it, in theory, reports all threading bugs. It doesn’t however address the first issue, making the code easier to write.

Testing with Deterministic Threads

Microsoft is going in a different direction. They are working on something called CHESS that makes your unit tests find multithreaded bugs. It does this by taking over the scheduler and sysmatically repeating each test, weaving the threads differently each time to exercise every possible way the scheduler could run the code. However it requires us to to write a set of tests that finds *all* the threading bugs. Since it is common to write unit tests with less than 100% coverage, a code coverage tool should be used to write more tests.

Conclusion

The good news is that there appears to be a variety of approaches to the problem and the whole answer will likely involve a combination of language or library enhancements and analyser or testing enhancements that are already in the works.

GWT for Web Applications

Clay Lenhart — Sat, 18 Oct 2008 10:47:01 +0000

There are several approaches for writing web applications, each with their own advantages. GWT is a new framework with its own niche.

Your standard ASP.Net (or JSP/PHP/etc) w/ Ajax and JQuery (or other Javascript library)
Java WebStart or .Net ClickOnce
GWT w/ Webservices

ASP.Net (or JSP/PHP/etc) – for Dynamic Websites

ASP.Net is great, because it will run on any browser, but it difficult and error prone to write Javascript code, and many times the application or site isn’t very interactive or responsive.

A coworker suggests that this is good for a “dynamic website”, rather than a full blown “web application”. It certainly has a web site feel, rather than an application feel to it. See the GWT demos below to see what I’m talking about.

Java WebStart or .Net ClickOnce – for Internal Corporate Applications

This, however, provides are great environment for writing interactive applications, however it requires either Java or .Net on the client. Some users do not have permissions necessary to install Java and .Net.

GWT w/ Webservices – for Public Applications

GWT is a great idea that compiles Java code into Javascript to give you an HTML/Javascript web application. It allows you to have *a lot* of javascript code that does not talk with the web server. Be sure to check out these GWT demos.

You can’t use the Java library with GWT, however you get a great GWT UI library, and you can call a webservice to do anything you like, for instance to make database calls.

As a C# developer, I find this great, because the learning curve is small. The Java language is so close to C#, and I don’t have to learn the Java library.

Advantages of Immutable Data

Clay Lenhart — Sat, 16 Feb 2008 19:44:01 +0000

I was reading about two of Google’s internal programs, Bigtable and Google File System, and how they handle a large amounts of data so that the processing is distributed (Bigtable) and the data is replicated (Google File System). One thing they both do is exploit immutability. So once something is saved to disk, that block of data doesn’t change. If you have a large volume of data, this assumption can be very useful.

Let’s say we’re talking about a transaction table for bank accounts. Records in the transaction table don’t change. Any corrections are handled by creating a new transaction record at the tail end of the table. If you are processing the transactions, this is great! You can ignore previously processed records since you know they will never change.