Free Newsletters

   All InfoWorld Newsletters
Reality Check | Ephraim Schwartz » Intel has a gripe with the software industry. Is Moore's law becoming a software afterthought?

May 25, 2007 | Comments: (0)

Intel has a gripe with the software industry. Is Moore's law becoming a software afterthought?

The saying "the more things change, the more things stay the same" was never more evident on Friday when Intel and Sun sponsored a roundtable discussion on hardware and software development for the press in San Francisco .

The change was represented by the fact that Intel no longer makes single-core processors in favor of only multi-core processors. What has stayed the same, at least for the past 12 years that I've been dealing with Intel, is the Intel mantra: The software has to catch up to the performance of the hardware.

Back then, Intel used a subtle approach. Whenever the chip maker unveiled a new chip, it would have its software partners on hand to demonstrate applications of the future that would use every cycle of processing power put out by the latest processor.

At the roundtable discussion, however, Intel was more into the blame game. This time Shekhar Borkar, Intel Fellow, director of microprocessor research, expressed his obvious frustration by saying he had a "complaint" with the software industry for not creating applications that can take advantage of parallel processing.

"It is imperative that software has to double the amount of parallelism [it can address] every two years," Borkar said.

However, when asked later in the discussion what will happen if they don't, his answer was weak. He said if one company doesn't do it, a competitor will.

That may be true but two things seemed even more obvious to me.

One, the software industry has a lot more on its plate than parallel-processing-enabling its applications.

The industry is going through great change at the moment, mainly with regard to Web 2.0, and here the network and performance through the network is driving much of software development. See companies like Akamai, and Citrix who are looking at ways to deliver and execute applications in the network, and Adobe, whose Apollo project is looking at a way to create hybrid applications that start in the network and finish on the desktop.

The other obvious truth is that this is not a technology problem for the software industry but a business problem.

Intel's business model requires that it must sell its chips in the millions and so far the only way they have come up with to do that is to tout the chips' performance, and to a lesser degree, the power savings on mobile devices.

I contend that if the software industry had the same business model, it would have solved the problem of how to use parallelism in its applications years ago when it was first briefed by Intel and others on this technology.

Rather, the software industry has a different business model, and other problems to solve that include inter-operability, integration, SOA, ease-of-use, consumerization of the enterprise, Web 2.0, software as a service, master data management, compliance, e-discovery, the list goes on. While performance is always needed and appreciated, the goals are far more complex.

I think it is disingenuous on the part of Intel to chastise the software industry as it did at this roundtable when it is obvious Intel has a vested interest in making performance the goal of every segment of the high-tech industry.

Nevertheless, Borkar continued to chide, saying that since Intel comes out with a new multiple of its multi-core processor every two years, the software industry has two years to go from 2-way to 4-way, and two years again to go from 4-way to 8-way.

In a moment of candor, Borkar did say, "If the software doesn't keep up, the chip becomes a paperweight."

One of the more interesting solutions that may not require software to keep up with the pace of hardware performance also came from Borkar, however.

It is called domain specific languages.

For example, you could write a program using a domain specific language just to address TCP/IP processing. And, if you want to write a program to parallelize TCP/IP you could write it just for that kind of network.

For further enlightenment I turned to one of the best and most widely quoted chip analysts, Nathan Brookwood of Insight 64 to gain a better understanding of the problem of creating multi-threaded aware applications.

Brookwood complied, in spades.

"To think how to code in parallel threads is an unnatural act," Brookwood told me.

By and large we think in a linear fashion, Brookwood said. Clearly grammars to think and express algorithms in parallel form are needed but most tools don’t do that.

Brookwood believes we are going to have to wait for the current generation of linear programmers to die off or get kicked upstairs into management and before we get a new generation that thinks parallel.

There is, however, a Sun tool or parallel development language, not quite productized yet, called Fortress that allows programmers to design applications that can take advantage of multi-core processors.

"When you write stuff [in Fortress], it is inherently parallel and if you want things not parallel you would have to go out of your way," Brookwood said.

The problem really is that multi-threading only helps a few computer applications that appeal to ordinary people. Sure it is needed for scientific computing but remember, as I said, Intel needs to create a demand among millions of buyers, not thousands.

The killer app does not yet exist and even Borkar admitted that.

Nevertheless, Brookwood does believe that over time it is important to create programs that are multi-core aware.

Up until now software developers had a free ride. Intel and AMD could make one, single, faster chip and the software ran faster. That kind of free ride ran out of steam and the new ride is multi-core.

"Multi-core is the new megahertz," Brookwood said.

However, it is more visible to the software than megahertz. It requires the programmers to think about and change what they are doing.

Unfortunately, that really hasn't happened. As Intel went from a single to dual thread, the ISVs created a whole bunch of narrow solutions that work with two threads, but they didn't think in terms of the bigger picture: multi-threading as a concept.

Now these same developers have to rethink how to make an application work from two threads to with four threads.

In the meantime, Intel doesn't want to wait five or ten years to make sure its processors don't turn into paperweights.

But I think they may have to wait, and over time the industry may take us in so many new directions Moore's law may become a mere afterthought.

Posted by Ephraim Schwartz on May 25, 2007 01:59 PM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




If Intel is really serious about the software
apps not taking advantage of multi-core
processor capabilities - it's really simple -
provide some software reference implementations
that show the software world how it is done.

Posted by: David Bardwell at May 27, 2007 11:17 AM

Intel is serious about multi-core and software. I hope you will join us at the Intel Sofware network: http://softwarecommunity.intel.com/isn/home/
visit the multi-core community to see learning guides, code samples, and developer tools.

Elliot Garbus
GM, Developer Relations Division, Software & Solutions Group, Intel

Posted by: Elliot Garbus at May 28, 2007 08:18 PM

There have got to be more than 64 applications on my computer right now, therefore I am good for many years to come. Once I get 67 processors things will get tense.

As time goes on I run more and more always-on software, like a local HTTP server, and more and more real-time software, like audio video stuff. Why shouldn't each movie in QuickTime Player have its own CPU decoding it at full frame no matter what the codec? When I have a 10 meter diagonal display with 300 pixels per inch resolution, maybe my window manager will actually be 20 separate window managers each managing a portion of my ridiculously large display, each with its own CPU core to work with.

If you are always connected to the Internet, maybe you want your firewall and security software running all the time on its own CPU core. Maybe it will need 8 cores just to do the kind of math it will have to do to keep the Internet of 2015 outside of your box.

We may be laughing at the idea of extra CPU cores as paperweights in just a few years like back when 640k was enough RAM for anybody.

Posted by: Fred Hamranhansenhansen at May 29, 2007 02:44 AM

There are ways to parallelize apps other than using special languages like Sun's. The use of declarative, domain-specific languages like SQL let developers express what they want while complementary tools can care of decomposing and parallelizing the actual implementation, such as on complex queries.

Ultimately, there will be a range of methods and tools for easing development of parallelized applications for multi-core. What's clear is that these will be based on higher-level methods that abstract the "unnatural" parallelization effort away from the developers themselves.

Posted by: Jan Liband at May 29, 2007 05:13 PM

The server room will go parallel quickly. Virtualization can shoehorn many single-thread systems into a multi-thread box. Then infrastructure apps will go parallel - DBMS, web server, search. Next ERP and other enterprise apps. Benchmark battles and cost per transaction mean a lot in those markets.

Business itself is parallel - my bank transactions can be processed in parallel with yours. It does take a change in viewpoint, may be facilitated by SOA and transactional thinking overtaking historic batch approach.

Desktop is trickier. Games and media will likely lead the way. Intriguing to think about a version of Excel that can update cells in parallel. Could imagine Word spinning off threads for spell check, re-paginating...

Posted by: Nick Fiekowsky at May 30, 2007 10:57 AM

Why should the general software developer care about multi-threading or multi-processors? The hardware and OS should provide the support. Every app could run in it's own thread. I shouldn't have to wait on windows explorer because IE is busy. All Intel has to do is get MS to move to a real 64bit os and work with the linux folk.

Posted by: bruce lill at May 30, 2007 11:38 AM

Too bad Intel didn't help OS/2 survive. Many of its native apps are multi-threaded based on multi-instance modules and have been since the early 90's....

Beyond that, few apps *really* need it. Science apps, graphics rendering, servers, games, and industrial motion-control (1cpu for Windows, one for the real-time motion kernal) are the only ones I can think of off the top of me head. For most office apps heck, person can only type so fast!
Cheers!

Posted by: Richard Budd at May 30, 2007 03:30 PM

Hmm. Intel wants a killer app to use their cores? How about a return to *gasp* the thin-client - for the home! Stick what's now become basically a mini-mainframe in the basement and network-booted terminals in every room. It of course would also handle the telephone & entertainment needs as well. That should eat some cores for Intel.
Cheers!

Posted by: Richard Budd at June 2, 2007 05:25 PM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links