X
Business

Does IT really need to fear multicore?

While multicore chips hold great promise for applications and computing power they could wreak havoc on technology departments.That's the message from Gartner analyst Carl Claunch, who argued Thursday that IT types should fear--yes fear--multicore technology.
Written by Larry Dignan, Contributor

While multicore chips hold great promise for applications and computing power they could wreak havoc on technology departments.

That's the message from Gartner analyst Carl Claunch, who argued Thursday that IT types should fear--yes fear--multicore technology. Multicore chips carry multiple brains on them and companies like Intel are pushing a core arms raise. The more cores the better--even though applications providers haven't quite caught up yet.

Why will multicore be an issue? For starters multicore technology can be a budget buster. Among Claunch's multicore points at Gartner's Symposium ITxpo:

  • You'll need new coding skills in house;
  • You'll need new development tools;
  • There are multiple core designs that will affect your software;
  • Your existing software licensing deals become more complicated;
  • And the impact on applications varies immensely.

All those wild cards and it's not even clear whether your old programs--and you know you have dozens of legacy apps lying around--won't run faster.

Claunch explains in his presentation:

We have had the easy fix for decades to deal with existing applications whose requirements have outgrown their current system — we refreshed the technology and the application ran better. This led to relatively long life cycles for applications, allowed operations to address application performance problems easily and required little advance notice of capacity shortfalls. Now, a performance issue may require substantial recoding of the applications, shortening life cycles, increasing the cost of modernizing portfolios, and introduce the need for good long-range forecasting of such performance issues.

There's also the staffing conundrum. Where are you going to find these programmers that can handle multithreading and parallel processing? Microsoft is just beginning to go down the multicore route, but when it does multiple applications may have to change. The majority of applications don't exploit multicore servers with the exception of Microsoft SQL Server or an Oracle database. But when the multicore app bandwagon fills up there will be some planning hassles.

Naturally, this software revolution is going to cost you more money--most likely. Claunch explains that software vendors will charge by the socket, chip, core or thread. But various designs from the likes of Sun, Cray, Intel and others will "produce seemingly illogical price differences when the same software, handling the same workload, is put on different systems."

In fact, Claunch reckons that Oracle's pricing, which is based on a ratio of computing power that varies with different chip architectures, won't last for long.

Claunch says:

The correlation between user workload and license charges will swing widely from model to model, vendor to vendor and year to year, further stressing the processor-based pricing models. As a consequence, methods such as the ratios used by Oracle will not be sustainable for long. All software vendors will be challenged to find a method that behaves logically for users, performs well for their businesses and can be explained easily.

And you thought your licensing scheme today was unbearable. It's likely that your software costs will rise as vendors as core inflation results in price inflation even if older applications don't improve dramatically.

Toss in the need for new programming languages, staff and software licensing schemes and multicore is going to cost you.

Luckily Claunch has some tips:

The first point--the "attempt" part--is interesting. Multicore will have you going to your software vendor in the name of fairness. Doesn't exactly sound like you'll have a lot of negotiating leverage in that scrum.

Editorial standards