Dr. Dobb's Journal July, 2005
Bayesian Classification
Dear DDJ,
I always wanted to know how to do Bayesian classification, which is why John Graham-Cumming's article "Naïve Bayesian Text Classification" (DDJ, May 2005) was so very helpful. I wrote my own implementation that deals with some of the shortcomings of the Perl version—and in 41 lines of Ruby code (see Figure 1). I have continued development of it at http://rubyforge.org/projects/classifier/.
Lucas Carlson
lucas@rufy.com
A Language for Concurrency
Dear DDJ,
I found Herb Sutter's article "A Fundamental Turn Toward Concurrency" (DDJ, March 2005) very interesting. I had not known that Intel had finally hit "the wall" in processor speed! The basic point that we need another fundamental revolution in programming paradigms is a good one. I suggest that the Ada programming language is part of the answer. It has an excellent model of concurrency, including lock-free concurrency, accessible to the average programmer. It is a fully object-oriented language, with strong typing and encapsulation. It has excellent support for generics. It has been around for 20 years, but is still current—it was first standardized in 1983, updated in 1995, and is in the final stages of being updated again, partly to add Java-style interfaces for multiple inheritance. So it is a mature technology; as Herb points out, it takes a mature technology to power a truly widespread revolution. See http://www .adaic.com/ for more information on Ada.
Stephen Leake
stephen_leake@acm.org
Multicore and More
Dear DDJ,
In his "Editorial" (DDJ, May 2005), Jonathan Erickson mentioned that "multicore processors can run at slower speeds and lower voltages, but still deliver higher performance. That's the promise anyway." When Sun released the UltraSparc IV dual core, this processor ran at the same MHz rating of the UltraSparc III single core. From a pure benchmark perspective, it was a near linear 100-percent speed increase. This had made our organization consider upgrading to multicore systems instead of adding another two-processor CPU board to our existing platform. When migrating from our six-processor UltraSparc III to a four-processor (8-core) UltraSparc IV platform, we noted an increase in processing power of approximately two CPU units on our combined application and database server. From a practical standpoint, it worked like a charm.
This year, we are expecting to add another four CPUs (total of 16 cores) to our application (as we shut down old internal systems). Next year, another four CPUs (total of 24 cores) will probably be added, as we shut down more help-desk systems. As an architect, dual-core systems from Sun has delivered on its promise and continues to. Jonathan also mentioned that "Intel plans on having devices with 4 cores running up to 8 threads each by the end of the decade." In 2004, the first 8-core [processor], four threads per core (32 threads) [was] struck in silicon by Sun with shipment projected in 2006 (http://www.varbusiness.com/sections/news/).
As a final note, last year, we consolidated dozens of large SMP help-desk systems (some Solaris and some Windows onto a single Solaris platform), some of which have not been rebooted since 1999 (Solaris 2.6!). With uptime like this, multicore capacity, and pure CPU socket counts—the pressure is really placed upon the developers to get their code modular so applications can be upgraded without stopping user activity. We need to focus much more closely on application availability, OS scalability, and application scalability in relation to user community expectations from developers in magazines such as Dr. Dobb's Journal.
David J. Halko
davidhalko@netscape.net
DDJ