February 20th, 2007
Targeting development for future hardware
Recent products from IBM and Sun have brought diversity, and thus choice, back to the hardware market. In particular, developers with hot ideas a year or so away from marketability now face some difficult choices that simply weren't there before.
Imagine a product idea, lets call it "Canary", based on going through every bit of transactions and communications data a customer produces to look for minor trend changes that correlate with discussions on popular web sites.
Canary's goal is to provide management with early warnings on market change - for example, if Canary's customer sells bread it could alert management to the existence and nature of a problem in its Canadian operations if a divergence between actual and predicted retailer orders for "organic whole wheat" buns correlated well with growth in web postings mentioning the new Canada Food Guide.
Canary would naturally have three distinct parts: a piece that sits in the customer's data center sucking in everything that goes by, a piece that sits in the developer's data center abstracting web discussions of interest to its clients, and a piece that does the analytic work needed to pluck information from the confluence of the other two data streams.
Two of these three pieces fit well with directions Sun is taking. Specifically Sun's x4500 is the obvious choice for the customer site data storage job because the combination of Solaris on 4 AMD cores and 16GB with up to 24TB of ZFS storage is faster, cheaper, and easier to work with than anything else on the market.
The hardware, and therefore development software environment, for the web hunter is equally obvious: success will mean running thousands of concurrent threads and dozens of concurrent encrypted connections to client sites - making Sun's CMT/SMP technologies under Solaris the no brainer choice.
The choices for the main analytical processor, however, aren't so obvious. First, that machine will both use sensitive data and be network connected, and so can't be x86 for security reasons - but the machine will typically be CPU bound on single processes with lots of repeated fast fouriers. In other words, the current generation Sun T1 certainly isn't the right answer and the developer therefore has to choose between betting on Sun getting Rock out the door on time and spec or looking outside the Solaris envelope for a solution.
IBM's Power6 looks like a good choice because it will run Linux at high gigahertz and include an Altivec short array processor -Sun, incidently, has comparable SIMD capabilities built into SPARC but they don't tell anybody and so most of the third party libs and tools our developer relies on, won't make use of them.
From a developer perspective, therefore, the decision to put a Power6 machine in this role has some attractions: it reduces uncertainty about performance, adds the IBM name to the marketing package, and offers a downstream route to cell.
On the other hand, everything about IBM costs more, code developed specifically to use the Altivec facility will be almost impossible to port to some other environment without a full rewrite, and the coding skills needed may be difficult to come by.
What this means is that what we have here, for the first time in years, is uncertainty and therefore choice: an actual decision to be made mainly on both cost and technical grounds. And that's utterly amazing - just when we think hardware has finally become a commodity, PPC and SPARC march off in complementary directions and leave us with choices again.
What can I say? Ka ching!? well, maybe; but cool? oh, for sure.
Paul Murphy (a pseudonym) is an IT consultant specializing in Unix and related technologies. See his full profile and disclosure of his industry affiliations.
Subscribe to Managing L'unix via Email alerts or RSS.
| 02/20/07
