In search of killer threaded apps

In search of killer threaded apps

Summary: Wanted: Killer applications that take advantage of Intel's threading technology inherent in multi-core chips. The goal: Develop software that best uses multi-core chips and take computing to the next level.

SHARE:
TOPICS: Intel
12

Wanted: Killer applications that take advantage of Intel's threading technology inherent in multi-core chips. The goal: Develop software that best uses multi-core chips and take computing to the next level. Must be fluent in geeked-out terms such as parallelism. Contact: James Reinders, director of marketing and business at Intel's software developer products unit.

That intro sums up Reinders' mission. Reinders--who joined Intel in 1989 and has worked on the world's first TeraFLOP supercomputer, compilers and the architecture of a bevy of processors--serves as Intel's evangelist to the developer community. His mission is to get software developers to think different and build applications that take advantage of the threading technology. Intel's obvious payoff is to sell more chips.

In a nutshell, threading technology, found in multicore chips, allows software to run in parallel on a computer. Think graphics rendering in the background as you work on something else or play a game.

Sounds great, but Reinders, who stopped by CNET offices in New York Wednesday, has a bit of a slog ahead. After all, there aren't any huge killer apps taking advantage of Intel's threading. When asked about killer apps, Reinder didn't have any readily available. However, there are some small wins and the launch of Vista may help move threading forward.

"We're working from the ground up and engaging the community," says Reinders. "We're trying to help developers understand how parallelism affects them. Developers haven't focused on threading applications, but I have faith that they'll find it interesting."

One example: JAlbum has optimized for threading technology unbeknownst to Reinder. The payoff: Web thumbnails render quickly. Reinders didn't notice until performance improved and he read the "read me" file.

Here are some highlights from the interview:

--Where will threaded killer apps appear first? Reinders said most likely places would be in audio and video applications, gaming and heavy computational software. For instance, Pixar would have an obvious use for threaded applications. "Most don't worry about how applications run, but a transition to high definition will consume a lot of CPU. High definition will speed the transition to multicore," says Reinder.

Those comments put Intel's relationship with Apple into a new light. Enterprises and people that do heavy video and audio editing often use Macs. Meanwhile, high-definition photos are also manipulated on applications like Adobe's Photoshop, which often appears on Apple computers. Connecting a few dots, it would stand to reason that Apple is more important to driving threaded applications than Microsoft's Vista launch.

--Is multicore a tough sell to enterprises? Reinders acknowledged that no CIO is going to go to multicore hardware unless it's explained in simple terms like your SQL will run faster and you get more power for less money.  Intel is hoping to piggyback on an enterprise Vista upgrade cycles.

--Will rich Internet experiences matter? "The most immediate benefit is that servers can react to a lot of users quickly," says Reinders. "That Web sites will be more responsive even as they become richer and more interactive."

--How long will it take to sell threading to developers? Reinders didn't have a timeline, but it could take awhile. Developers are still working through how parallelism impacts them. They also have to see the benefit of making their applications run faster. "They appreciate it when parallelism is implemented, but they don't think it through at the beginning."

--How is Intel supporting developers? Reinders notes that Intel offers tools, compilers and libraries that are "production worthy" to help get the ball rolling. Tools are very important given that applications running in parallel can collide in "deadlocks." Intel has software tools that can synchronize various operations to keep the software trains running on time without collisions. In addition, Reinders is spending some time watching how code libraries interact since threaded applications can present problems. He's currently pondering taking some of the tools open source.

Topic: Intel

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • Factual Error

    I though Hyperthreading was not available on Core2 multicore Intel chips.

    "...Hyper Threading is not supported on any Core 2 CPU currently on Intel's roadmaps..."

    http://www.anandtech.com/printarticle.aspx?i=2795
    t_mohajir
    • interesting

      he referred to threading, parallelism and hyperthreading as though they were interchangable. I'll change to threading to be safe and then followup.
      Larry Dignan
      • indeed, hyperthreading is something different

        Hyperthreading is not the same thing as true multithreading. Hyperthreading is specific to P4 chips and in certain situations results in lower performance when it is enabled. Hyperthreading creates a "virtual processor" which allows the processor to perform some tasks in parallel, but it's a hack at best. Multicore chips such as the Intel Duo chips and AMD X2 chips are effectively two processors fused onto one chip and fully support multithreading.
        boxmonkey
  • Ask Apple!

    I have been using multi-threaded apps for the Dual G5 processor for years. Maybe they can help!
    nomorems
    • RE: Ask Apple!

      Nice, but we are talking real world here.
      joe6pack_z
  • There are tons of threaded apps out there!!

    What on earth?? I can't believe Intel would not know this...Larry?
    Techboy_z
    • Yup

      DVD Shrink is one example, but there are many others. The problem, if you want to hype this stuff, is that there aren't any awesome programs that require multiple cores, they all just run faster with multiple cores.

      The important point that people so often don't seem to grasp however is that even when running single threaded apps, your system tends to "feel" faster because it doesn't get bogged down when an app is working hard. If one CPU or core is maxed out, windows can still do everything it needs to in a timely manner on the other CPU.
      boxmonkey
    • threaded multicore apps

      Intel has a whole unit set up for get developers on board with threaded apps so that alone would indicate there aren't a whole lot of apps out there that would <i>spark big adoption rates</i>. He didn't say that there were no threaded apps at all--he said there were no killer apps. Intel doesn't view the the current state of affairs as taking advantage of the multicore setup.
      Larry Dignan
      • And almost forgot

        No one has a clue what a killer app would be for these chips. That's why Intel is doing the grass roots developer approach. There's some person in a basement somewhere that has this great threaded app that needs to bubble up. My hunch is this is going to take some time, but who knows.
        Larry Dignan
        • Doubtful

          Multithreaded apps work just fine on single processor machines, just slower. There's no way around that. Any app that screams on a dual core system because of threading will also perform well on a faster single core processor. Anyone waiting for that to change dramatically has a long wait ahead.
          boxmonkey
  • Has anyone checked the process list of task manager?

    Internet Exploder: 30-33 threads
    Outlook: 25 threads
    Winword: 8 threads
    MSDE: 23 threads

    Not that it has helped these packages, multithreaded or not IE and Outlook are still dogs even though there are uninformed people that consider them to be killer apps.
    balsover
  • The friction point

    I think the friction point with multithreading is that developers have to tell the computer "do this task asynchronously from the others". Part of the problem may be the programming languages we use, which are based on the linear execution model. I don't know. I figure it's difficult to adapt that model to multithreading. I think the real key is to make multithreading transparent. Make it so the programmer doesn't even have to think about it if they don't want to. The compiler/interpreter/VM could break the program into tasks, spawn the threads, sequence them, and create a program that works as specified.

    Programmers should be focused on meeting the logistical requirements of an app., not how tasks can be broken up so they can be executed in explicit threads.
    Mark Miller