Multicore processors have been around since 2005, when Intel shipped its first dual-core processor.
Since then the company, and its competitors, have standardised on quad-core processors and will soon move to six-core processors. Intel has even demonstrated 80-core processors, although it is likely to be many years before these are commercially available.
Intel's figures show that increasing a processor's clock speed by 20 percent provides a 13 percent performance boost but a 73 percent jump in power consumption. If clock speed is dropped by 20 percent, there will be a 49 percent reduction in power consumption but only a 15 percent drop in performance. This illustrates the potential of dual- and quad-core processors, according to Willie Crowe, an enterprise solutions architect with Intel.
"The great advantage of multicore is that you get a large boost in performance in return for a relatively small boost in power consumption and clock speed," says Crowe. "With a six-core processor, you're getting six times the performance for less power and capacity."
Software vendors taken by surprise
However, although the new technology has its benefits, not least improved performance, the impact on the software industry and its customers has been disruptive in the extreme, argue analysts.
"Pricing for multicore processors is incredibly confusing, highly complex, and it's virtually impossible to compare like with like," says Clive Longbottom, a research director with Quocirca. "It's getting a little better but we still have a long way to go."
Longbottom claims software makers were simply unprepared for the changes that multicore processors would have on their business models. "When this stuff came out, the vendors were completely caught with their pants around their ankles," he says. "Nobody knew what they should be charging for customers who were running software on these new systems."
At the heart of the issue is how vendors should charge for software running on multicore processors. Traditionally, software users have paid a licence fee based on how many processors were used to run an application. So, when dual-core processors were announced, some software suppliers simply charged double for software running on dual-core systems.
This model was unpopular for a number of reasons. Firstly, vendors did not always agree on what constituted a processor. While Intel, AMD and Sun argued that a chip socket counted as a processor, IBM took a different approach, but only for certain platforms.
Customers, meanwhile, complained about paying for two processor licences when a dual-core processor did not perform twice as fast a single processor. The result, explains Longbottom, was the emergence of staggered pricing systems, which charged for processors on a sliding scale — for example, charging 100 percent for one processor, 180 percent for two processors and 210 percent for three. "The problem was that it made no sense to people, and the figures didn't tally with what users saw."
Charging by CPU also makes it difficult for IT managers to predict how IT budgets will change over time, adds Julie Giera, a vice president with Forrester Research. "You might buy an application to run on four cores and it makes financial sense, but, if you want to take advantage of new hardware, your application might become unaffordable running on six or eight cores," she says.
During 2006 and 2007, there was a lot of "thrashing" in the market, says Crowe, as vendors tried to work out pricing models that would make sense to customers. "I think we're in a situation where things are getting clearer and we now have a spectrum of pricing options," he says. "At one end, there are companies pricing per socket and, at the other end, are companies that are pricing by using some multiplication or combination of factors, such as millions of instructions per second (MIPS) or transactions at the other end."
That spectrum includes a range of pricing systems and models, with some vendors providing different pricing structures for different platforms, products and customers. Some vendors have built their pricing models around MIPS and how much power is available to the application. "The problem here, of course, is that it's often impossible to say what power is being used by what application, particularly in a grid or virtualised environment," Longbottom says. "Managers are paying over the odds because they don't know how many cores or what percentage of those cores are being used to run an application, and the figures could be dynamic."
With partitioning, a fraction of a processor might be responsible for running an application – but how should this be costed? Moreover, virtualisation is designed to be dynamic and scale up and down as needed. Do customers pay for maximum capacity, average capacity over time or something else entirely?
Choosing the best pricing model
As an IT manager, how can you begin to compare the various pricing models available and judge which will provide the best possible value? "It won't be easy and you'll need to do a lot of work during the specification of the architecture," warns Roy Illsley, a research director with Butler Group. "But it can be done."
The first step is to begin by asking what the business needs from a software application. How resilient does the application need to be? How many users will...
