English | 中文 | Русский | Français

2,856 Posts served

8,606 Conversations started

Poll Result: Expectations for 2008's Most Important Advance

By Kevin Farnham (107 posts) on February 2, 2008 at 9:16 am

The January Threading Building Blocks poll asked developers to select the area where we'll see the most important software development technology advance in 2008. The 43 responses produced no clear consensus.

Here is the actual poll statement and the results:

The most important software development technology advance in 2008 will involve:

• 32% (14 votes) - Scalable server technologies
• 30% (13 votes) - Web development technologies/frameworks
• 21% (9 votes) - Desktop client/application technologies
• 12% (5 votes) - Other
• 5% (2 votes) - Don't know

In reality, we'd expect there to be advances in all of the specified areas. To me, the advent of multicore computers has far reaching relevance especially with respect to server and desktop technologies. Whereas today we have server farms consisting of thousands of single core systems, in the future it may be a better option to reduce the number of distinct systems by utilizing fewer many core systems instead of more single core systems. It would seem to be simpler and more cost-effective to maintain fewer physical machines. And in the case of server technologies, applying multicore machines wouldn't necessarily require multithreading the software. If you replace eight single core machines with a single eight-core machine, you would just run eight separate instances of your software on the eight-core machine.

With respect to desktop applications, there is a lot of disagreement over whether multicore represents a crisis, a challenge, or just a bunch of hype. I find it impossible to believe that developers and application vendors will ignore the quadrupling (and more) of processing power that will be soon available for homes and offices at relatively modest prices. Historically, software has easily kept pace with increases in memory and processing power, forcing all of us to buy new computers every couple years if we want to be able to run the latest applications.

Multicore presents a challenge, in that for an individual application to take advantage of the new processing power, it has to be multithreaded. And, it is quite true (I say this from having done it for more than a decade) that multithreading applications using traditional methods (using pthreads or Windows threads) is difficult and slow. But that's why were are seeing this surge of conversation about concurrency and new methods of developing multithreaded applications, such as open source Threading Building Blocks and Erlang; it's also why Microsoft created its Parallel Computing Development Center.

It seems highly unlikely to me that all the people who are working on these projects are doing so because they've been blinded by multicore "hype." Much more likely is that we've reached an important road block with respect to increasing software performance, and people are working hard on the potential solutions. And we all know that the reward for "winning" (i.e., having your technology become one of the major platforms for developing concurrent applications in the future) can be enormous. Just ask Linus Torvalds, or Bill Gates (I'm sure we can all think of many others).

New poll: which TBB components have you used?

A new poll has been posted on the TBB home page. The question and response options are:

Which class of TBB component have you applied the most thus far?

• Algorithms (parallel_for, parallel_reduce, pipeline, etc.)
• Containers (concurrent_vector, concurrent_queue, etc.)
• Memory allocators
• Mutexes and atomic
• Tasker
• Most or all of the above
• None of the above (I'm just getting started with TBB)

Please consider participating in the poll. Your responses may assist the TBB development team in determining where to focus some of their future efforts.

Kevin Farnham, O'Reilly Media, TBB Open Source Community, Freenode IRC #tbb, TBB Mailing Lists

Download TBB

Categories: Open Source, Parallel Programming, Threading Building Blocks

Comments (3)

February 4, 2008 12:20 AM PST jmuffat Total Points: 175 Registered User

Algorithms and Allocators. If you ask me a month from now, I'll probably have used it all. This is a fantastic package and I can't wait for when you'll have come up with a way to keep busy during IO... As of multicore being popular because of some road block that people would clearly see, I'm not convinced. I think it's just easier: say you have a bit of code that you have written neatly but haven't started optimising aggressively. Waiting for faster processors won't help. You can go the good old way and optimise the inner loop, SIMDing your way to performance and using all the tricks of the trade. This is *hard*, and might get you somewhere around 2x. The novelty is multicore, with multi>2, (Quad and dual-Quad). Here, you optimise the *outer-loop*, this is comparatively much easier, and can get you to 2x and beyond a lot faster than SIMD. And then, if this isn't enough, you can still optimise the inner loop. And wait for processors to be faster...

February 12, 2008 5:13 AM PST Oleg Gatafari

I agree that many programmers will sooner or later have to face the realities of programming for multi-core - specialized parallel libraries for different application areas will make some tasks easier but general libraries such as Tbb from Intel, TPL from Microsoft and Jibu from axon7 will be necessary for more general apps.

February 20, 2008 2:31 PM PST Bill MacGregor

I sure hope that Intel makes sure that all new Processor Family's will completely support Open Source OS`s. It would be funny if All of the Intel Computers in Germany that run Open source software could not be updated :) please email me when Intel converts world wide to Open Source I will "short" M$ stock and retire Bill MacGregor ps Do not work to hard on M$ OS`s , its a waste of time. Open Source and Mac`s will be the choice of the world.

Trackbacks (0)

Leave a comment