Over in Paul Murphy’s Managing L’unix blog on zdnet, he does an overly simple analysis of simultaneous Multi-threading (SMT) architecture systems versus more traditional multi-core/SMP systems and falls to at least one common misconception and misses the point technically, architecturally and operationally.
Of course I would say that…
In comparing Sun’s x4500 with Power6 he comes to the conclusion that “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.”
He then goes on to state that for the scenario he uses the choice of a backend, analytic system isn’t straight forward, and goes on to look at the advantages and disadvantages of both the x4500 and Power6 based systems, tipping his hat to a Power6 based system but then concluding “IBM costs more”.
This just misses the point both technically, architecturally and operationally. First technically, his argument for the x4500 requires the use of thousands of concurrent threads. I’ve spent a reasonable amount of time looking at this and while you can make an argument for it, it just isn’t the direction the industry is taking in general. No matter how you spin it, programming thousands of concurrent threads isn’t simple. Sure, you can virtualize them in containers, virtual machines or partitions and split the problem up, but then you are really defeating the purpose of an SMT system.
It also very much depends on the workload. Sure having a lot of threads sitting around waiting for something to happen on the web is about as simple as it can be from a programming perspective, no locked data, no shared queues, no thread reuse etc. But wait a minute, don’t waiting threads consume power, don’t they use memory etc. ?
This is where both his argument and his “cost” analysis come apart. Operationally we’ve seen way too many organisations follow the Amazon/Google/ebay server model without really examining why they started down this route, how they got there, the costs involved and why they persist with such an architecture.
A better scenario would indeed be some number of high-end Power6 servers running all the workloads, managed by service level. In this environment, the “thousands of threads” could be satisfied by dozens of mirco-partitions. More partitions can be added simply and quickly through standard operational procedures, or through automated provisioning. Systems no longer needed can be deactivated or re-provisioned for other workloads.
In this environment there is little or no non-standard programming, no complex thread management etc. You are essentially running a scale-out Amazon/Google/ebay architecture on a scale-up machine. This has one big advantage in that it can also handle the back-end analytic, transactional and/or database work concurrently, through micro-partitioning, workload partitions etc. And yes, in a second nod to Paul, I agree with some of his assertions about programming in the Altivec instructions.
Operationally the IBM Power based server is the much the smarter model. It just isn’t the commonly accepted one as we have not really marketed it that way. Drastically reduced power and heat requirements, dynamic re-use of the servers as workloads change, no servers sitting around idle when the business priorities change and you are left with a machine which simply isn’t suitable for general purpose use.
You can’t make a decision based on “cost” when Power6 isn’t even formally announced. Look no further than last weeks IBM 560q Power5 for an example of the like for like economics!
So yes Paul, choice is a good thing, provided you don’t make the wrong decision.