IdentityMine

| Tags: Evan Lang, WPF

originally posted by Evan Lang (link) - please comment at original post.

It’s been a while since I’ve said anything here (actually I haven’t said much at all), but I wanted to share a general philosophy I take towards multithreading. I’ve seen a number of misconceptions out there, many of which I shared for some time, that I’d like to comment on.

In my area of specialization, performance is critical and is always near the top of my priority list. I used to be of the opinion that with all the worries about task switching, synchronization object, message handling, etc., that having multiple threads should generally be avoided whenever possible. I understood that sometimes it greatly simplified the design of certain things, but generally figured that simplification came at a cost. The apps I wrote did perform well eventually, but were often incredibly difficult to properly design and maintain.

On the other hand, I have also found a number of developers who take the opposite approach. Their general philosophy almost seems to be that if any object operates “independently” to some degree, then it should be in its own thread. These are not the same people who tend to overemphasize performance, and when using their applications, I do tend to notice a significant hit.

After some thought and experience, I’ve come to realize, naturally, the ideal solution is somewhere in the middle. Back when we only had one CPU, and no DMA controller, one thread was definitely the way to go to maximize performance, and my old philosophy was dead-on. In the future, it looks like the concept of a CPU and a GPU (which nowadays contain hundreds of cores) will merge into one hive processor. When that happens, the idea of wrapping each independently-operating object in its own thread will probably be the best way to go. The key variable in making the decision is the hardware.

What I’ve realized is that threads can boost performance as long as they can be logically bound to a specific piece of real, physical hardware. You can have one thread load resources from the internet and from the hard drive, another thread render your UI, yet another thread listen for user input, and finally a thread to perform all the logical processing on the incoming and outgoing data. Each thread is dependent primarily on a separate hardware component, which ought to be able to operate independently of the others.

When the day comes that we all have hundreds of processing cores at our disposal, I will start designing my threads around the independently-operating virtual objects I have in my system architecture. Until that day comes, however, it’s best to design threads around the available hardware, and have each module of your code operate within the most appropriate of them. For now, it’s still entirely possible and can be entirely too easy to create a system with way too many threads, so be careful how you treat them if you want to maintain reliable performance in your system.

Remember to please comment at original post: (link)

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on PinterestShare on RedditShare on TumblrEmail this to someoneDigg thisFlattr the authorShare on StumbleUpon

Comments are closed.