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

2,857 Posts served

8,606 Conversations started

Don't Thread! The End of the Free Ride

By David Stewart (Intel) (138 posts) on November 15, 2006 at 5:57 pm

So multi-core is here, and here to stay. Dual core, quad core, it's a done deal and not just from Intel. What amazes me is that SW developers are not reacting a lot more than they are.

Folks, the problem here is that we devs are accustomed to getting a free ride on the Moore's Law Express. Other than a few geeks who code to the newest instructions like MMX or SSE, devs can just coast along and ignore changes in the hardware. They have become addicted to the cheap crack of processors that just always get faster on them with no additional work.

The scary thing now, the thing that is really different from the previous 35 years of the microprocessor, is that the free ride is over. The chip designers have now given us technology that requires their friends here in the software world to adapt, or suffer from a performance loss, not gain.

The solution that Intel puts forward is to adopt threading. Threading packages of one sort or another have been around since the 80s. Intel adds to these with enhanced packages, tools that analyze your thread performance, check threading correctness, and even provide basic building blocks to code parallel from the outset.

The problem is -- and there is no way around this -- threading is hard! Unlike porting code from Windows to Linux or moving from 32 to 64 bits, there is no tool that is going to thread your code for you automatically. Intel has a lot of smart devs here, but there is no free ride on the threading train.

The reason why threading is hard is because it takes a lot of discipline to write thread-correct and thread-optimized code. Instead of just writing code which performs a function or delivers a feature, you need to think it through. Code it and recode it and experiment with it. Think to yourself, "do I really need to hold this lock here?" "Could I possibly deadlock here?" "Can I structure this better?"

Trust me, I know of what I speak here. When I was doing OS work for uniprocessors in the 80s and then had to move to multi-processors, it was painful. My productivity went down because I had to put a lot more thought into the art of programming.

Is there an alternative? Sure. Don't thread. Use the process model instead. Connect your processes using pipes and have done with it. You don't need to worry as much about disciplined programming and instead get back to feature development, which is what they usually pay us to do. I wrote about this in a previous entry, so check it out for directions.

Processing and piping,

Dave

The opinions in this piece are mine alone and do not reflect the official position of Intel on products or strategies

Categories: Intel® Software Network 2.0

Comments (5)

January 4, 2007 10:55 PM PST Clay Breshears (Intel) Total Points: 16,177 Status Points: 16,177 Black Belt

http://www.vmware.com/As I have posted before threading is not the only option you have in dealing...

January 13, 2007 5:44 AM PST JoelKatz

The process model is even less mature than the threads model. I think it's insanity to advocate the process model over the threads model. You think it's a hard discipline to write correct multi-threaded code? Try writing correct multi-process code. Want to keep a pointer to some shared data? Don't forget that it needs to be translated for each process. Oh, and every pointer inside every shared structure similarly needs to be translated. And guess what? Processes can race exactly the same way threads can. The difference is that with threads you have light fast synchronization primitives and with processes, sorry, you don't. As for connecting processes with pipes, that means that every time one process needs some information another process has, it has to send a request, context switch to the other process, the other process has to figure out what pipe it has to process (because it won't have a thread just waiting to do it), read the data, process it, write the response, switch back the other process (which is now blown out of the caches) and read the result. Comparing this to acquiring a lock and just accessing the data makes it clear that this only works when there is *very* little shared data. Try to write, for example, an MMORPG this way. I don't think you'll be able to do it. (And do you have one process for each user? How far will you get with that? And if not, what will you do if one user suddenly requires a lot of CPU time? What will happen to other users on his process?) Sorry, the reality is that people who develop server-type code are going to have to learn to multi-thread. That will be true until and unless we get process pool working, and that will likely be no easier than multi-threading.

January 13, 2007 5:47 AM PST JoelKatz

One more thing: If the question is "how can I get all the power out of this computer?" then you are right. Multi-threading is far from the only way to do that. But if the question is "how can I get all this power *into* my application?" then you are wrong. Multi-threading is almost always the best way.

January 15, 2007 7:33 PM PST David Stewart (Intel) Total Points: 9,435 Status Points: 9,435 Black Belt

Let's talk about implementing an MMORPG using threads cs. processes. As the number of users increases, tt the limit, you can't ever hope to build a machine large enough to host the entire world. So you need to have some way to factor the shared state database across multiple compute nodes. My point is with the process model, it becomes almost trivial to load balance the virtual world across compute nodes. With the threading model, it would take a lot more head scratching.

February 11, 2007 11:14 AM PST The Tao of Multithreading

There has been a shift in the responsibility for delivering faster performing applications. In the past,...

Trackbacks (0)

Leave a comment