Intel: Optimize applications for multicore

Intel is expected to release on Monday development tools designed to help programmers at software companies take advantage of the added computing power available on multicore systems.

The chip giant has forecast that by the end of this year, about 70 percent of its chips will be multicore. That is, each processor will host more than one processing unit, a design that increases performance without increasing power consumption.

A new product, called Intel Threading Building Blocks, is an extension to the C++ programming language used to ease the process of writing parallel routines, or threads, within an application, said James Reinders, director or marketing for Intel's developer products division.

Two of Intel's existing multithreading tools, called Intel Thread Checker 3.0 and Intel Thread Profiler 3.0, add support for 64-bit processors and the Linux operating system, he said.

Multicore applications do boost performance of existing applications because they are more powerful. But to have a more dramatic improvement, software makers need to write applications where separate tasks can be done in parallel, Reinders said.

"If you take any particular application, something like photo editing, none of it is taking advantage of parallelism," he said. "But photo and especially video editing is a pretty obvious place."

He said that Adobe has optimized its video-editing application Premier 2.0 for dual-core systems now on the market.

Adding parallel processing to existing applications is "a lot of extra work," Reinders said. With Intel Threading Building Blocks, Intel has made it easier to manage threads by automating some of the process of breaking down an application into concurrently run tasks, he said.

"It's not intrinsically harder to write threads, but developers need to get used to thinking that way and we need help from the tools," Reinders said. "In the serial world, it doesn't matter which order you do things or how you break them down."

[jpsalvesen]

Expect more bugs - initially

Multithreaded applications are harder to make - and harder to debug and test. Especially when you're inexperienced. And yes, it is harder than doing a web-app.

[joelkatz]

No more bugs

No, there won't be more bugs, for two reasons:

1) A lot of software is already multi-threaded, just badly so. A push to teach people how to do it right and get them better tools may well help them squash these bugs.

Windows drivers, for example, are all fully multi-threaded, and nothing does more harm than a driver bug. Anyone who writes drivers already knows how to write multi-threaded code -- maybe well, maybe not so well. This can only make that better.

2) It's actually very hard to write good single-threaded code for real-world complex problems. Most people who claim the reverse only work on 'toy' problems, not real-world heavy-duty applications like MMORPGs and video editors.

You must be absolutely incredibly careful to never ever block under any circumstances no matter what happens. This results in two kinds of bugs. In one where your intricate code to make sure you never ever block has bugs in it due to the complexity of the requirement. The other is where you still block because you missed one rare case. (This can cause major headaches with server apps.)

So lots of bugs will go away due to this push.

[Himanshu_Joshi]

woo..nice thing to start with

will be nice...programming will be hard but it will be useful as programmers can control each process on very first level how system should handle them... it will for sure increase the performance....

[L-Fire]

Wow, that's so new!!!

OS X has been multi-threaded at the OS level since the first dual-
processor Macs in 2002. Glad to see Windows developers playing
catch up once again.

[seduffy]

Wow, did you read????

"Two of Intel's existing multithreading tools, called Intel Thread Checker 3.0 and Intel Thread Profiler 3.0, add support for 64-bit processors and the Linux operating system, he said. "
Clearly states that this is the first multithreading tool intel has done, oh maybe not.

Multithreading is not new to windows, linux, or OS X. "Dual-processor" != dual core processors. This is mostly for application developers not OS developers.

I thought Apple was moving to Intel for their processors?

I don't see anywhere in the story anything about Windows or Microsoft.

I would try reading before flaming Windows.

[techprogress]

Your comment is pure garbage.

OSes that support SMP have the capability to perform multithreaded tasks. That DOES NOT MEAN the application developers USE that functionality. THAT is what Intel is talk about. They look to make it easier for EVERY developer, large and small, to actually USE SMP and MT support.

SMP capable OSes that support multithreading:
http://en.wikipedia.org/wiki/Symmetric_multiprocessing
Original Google search
http://www.google.com/search?q=smp+os+capable+of+multithreading

A partial list of SMP and MT capable OSes:

Microsoft Operating Systems:
Windows NT:
3.1 Through 4.0 Workstation supports up to two processors.
3.1 Through 4.0 Server supports up to four processors.
4.0 Server Enterprise Edition supports up to eight processors.
Windows 2000:
Professional supports up to two processors.
Server supports up to four processors.
Advanced Server supports up to eight processors.
Data Center supports up to 32 processors.
Windows XP:
Home supports only one processor. (Not verified.)
Professional supports up to two processors.

Linux, BSD, and other Unixes:
Linux:
All current distributions (2.4x Kernel) of Linux support SMP in excess of 32 processors. 2.2x supports up to 16 processors.
BSD:
BSD currently supports up to four processors. However, there is a serious development effort to improve SMP support under FreeBSD.
Solaris:
Solaris 8.0 supports up to 128 processors.

Unix:
There are too many flavors and variables to answer this accurately. Suffice it to say that virtually every Unix supports SMP.

Other Operating Systems:
BeOS:
BeOS 5.0 supports up to eight processors.
OS/2:
OS/2 Warp 4.0 supports up to 64 processors.

[aabcdefghij987654321]

OSX nothing

BSD (which OSX is built upon) had this capability years ago. Multi-processor systems are not some sort of new thing under the sun. How to create multi-threaded programs is an OLD topic, what Intel has done is simply provide some of the structure needed to make it easier for developers to take advantage of the fact that soon most systems will be multi-processor, something a lot of them ignored because the vast majority of systems weren't multi-processor.

But just to jump a little harder on your ignorant "OSX already has this, it's too bad you Windows folks are just getting this" nonsense I've been running multi-threaded, multi-processor capable Windows OSes since 1992. Again (since you seem to need repetition to retain any fact) the only thing "new" here is that Intel has provided some frameworks to make it easier to handle multi-threading in a multi-processor environment.

Try not to be such an ignorant bigot in the future.

[Hardrada]

yeah but what about the

2 or 3 applications that run on OS X? After all that's what the article is really talking about.

[bobby_brady]

You'd think they'd release this before the chip!

Why is it that software ALWAYS lags the hardware?

[jamie.p.walsh]

How do you test the software before the hardware exists?

....

[ojingoh]

premiere not premier

your spelling is wrong:
http://www.adobe.com/products/premiere/

[Hardrada]

only if they have to

the point here is there weren't a lot of consumer-level applications and workloads that benefitted from multi-threading to the extent that it justified the additional development effort. After all, how many consumers owned systems with more than 1 CPU before 2006?

Gaming, which has traditionally pushed the envelope for consumer PC hardware, has relied on offloading a lot of processor-related tasks to GPUs and add-in cards.

When Intel began ramping for multi-core on the desktop, they also began to train developers on writing parallelizable apps that could execute simultaneous threads. A lot of this training was a rehash of the work done in the MP server world, including stuff like openmp support in the compiler.

Intel is just making that knowledge and tools more mainstream, essentially lowering the bar to entry to appeal to a broader range of developers. At some point you might even find instructions for parallelizing your workload and building MP-safe applications on the back of a cereal box. ;)