|
I have been developing high performance cross platform solutions for nearly 20 years. Anyone can write a multi-threaded application but it takes real skills to write high performance multi-threaded applications that are truly parallel. There is a lot more to threading than using thread-safe functions and thread currency objects. Truly parallel applications can run almost lock free on multi-core systems. A lot of developers think they know everything there is to know about threading but in 90 percent of the project sources that I have reviewed they don't. For example, NUMA and system architectures are often overlooked when writing multi-thread applications that properly leverage parallelism.
After years of research and development in the area, I consider myself to be an expert in writing cross-platform solutions that leverage parallelism on systems that support it. I will admit that every now and then I encounter something that I didn't know.
Walter E. Capers
modified on Friday, July 9, 2010 2:36 PM
|
|
|
|
|
... that I really didn't even know what they were talking about. So I answered, "I let my Operating System do what it can".
|
|
|
|
|
I was one 
|
|
|
|
|
The current projects I work on are native code and ran fast enough on the hardware of their initiation, lowly Celeron/P4s of the c. 2002/2004 era.
That's still fundamentally the case, especially for one of them, which rarely hits more than 25% CPU even on a 900 MHz Celeron running XP.
I acknowledge that it's not the case for everyone though....
|
|
|
|
|
Most of the regulars know me. I solve big problems, use big machines, but mostly I draw pretty pictures for people. (hey, when push comes to shove, that is all I really do!) Yes, I am also the local parallel pusher (just had my parallel fix an hour ago too). If it is parallel, I use it, when not occupying my time fighting others in our company who don't. Our biggest machine is a dual-quad with dual GPU's -- in single threaded world that system is 500MFlop, in parallel and using everything inside to its advantage it is a 3TFlop calculating monster. The first supercomputer I worked on only did 380MFlop with 500 cores....
I use everything at my disposal, and I could have still checked the last item.... One of our programmers was soooo against threading that we mutexed the code into lockstep. I am still removing the damage. Admittedly I have a special case, reproducing the world we see around us cannot be done single threaded. Still I see so many people overlook areas where things can be threaded because performance doesn't matter (which is absolutely fine, as long as it is really true) and there is no need to do one thing while doing another (also fine, as long as it is true).
I hate our customers to wait. If my customer is waiting for something for even long enough to sneeze, I've got to find a faster way.
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
Seriously, and maybe it's due to the type of programs I work on, but thinking about things in terms of threads simplifies the design for me. Ever since I forked my first thread in the ftp server I wrote for a class as a sophomore in college, threading has made all the sense in the world to me. And this goes back to well before there were (commonly) multiple cores in home PC's. I guess some people just don't, or can't, think that way.
I did run into a deadlock bug the other day that seriously pissed me off once I realized what I had done. It was such a rookie mistake (the order of the locks was wrong).
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
|
|
|
|
|
David Kentley wrote: . It was such a rookie mistake
The rookie mistake I made last week still makes me blush.... The college kid I am helping apologized for writing the original, I told him that it was really my fault. He is the rookie and I didn't detect the nuance that needed the change in structure, but there is little chance he would have. Now we both have a great example of why the algorithm needed to be slightly restructured. I am still kicking myself, but at least the college kid will be taught right. He now understands why.
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
|
I use worker threads to avoid blocking the GUI thread but that's about it.
If you read 100 articles on multithreading you will have 100 multithreading techniques most of which say the other 99 are wrong.
|
|
|
|
|
|
ODBC articles were like that. Like you I stop reading when I get one to work
|
|
|
|
|
El Corazon wrote: all 100 are wrong, I haven't written an article about it yet....
I am joking!! I am! I am!
You wrote one but your bosses nuked it when they went paranoid?
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
I will martyr myself and be the first to admit that I don't think in terms of parallel programming at all.
Perhaps its the nature of the assignments I get. Perhaps a lack of the wherewithal to see the opportunities.
I won't even use the excuse that my employer's systems (including my own) are all single-core.
Will others dare to so bare their very souls before this august forum?
(Sigh . . . But now I feel a lot better)
/xml> "The difference between genius and stupidity is that genius has its limits." - Albert Einstein
| "As far as we know, our computer has never had an undetected error." - Weisert
| "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010
|
|
|
|
|
|
OK I will out myself too. I never worry about it. My code runs on my dual core desktop or on the single core target and I never worry my head about it. Sorry.
------------------<;,><-------------------
|
|
|
|
|
I think multi-threaded programming has gotten a bad rap, largely due to the cargo cult programmers filling the rosters out there. If they can't cut/copy/paste a solution into their app, whether it's appropriate or not, they say the technology's too difficult to use or worthless. This has led to all sorts of efforts to cover up the messy details with programming libraries, language features, or entire languages.
There is a substantial learning curve, but doing multi-threaded programming properly isn't impossible. I believe the hardest part of it is deciding which activities should be in which threads. Those decisions need to be made to balance the workload over the available resources, minimizing overhead. I don't believe any of the new solutions being offered improve on this essential requirement. If the developer makes poor choices on what he 'parallelizes', the application will still perform badly, regardless of the technique.
I'll admit my point of view is probably biased. The applications I've worked on for the last 10 years or so have all been multi-process and multi-threaded process control systems. Even the user interfaces tend to be multi-threaded, with UI stuff in one thread, communications in other threads, and worker activities in more threads as needed.
|
|
|
|
|
You can run a multi-threaded application on a computer with a single CPU, and nothing will run in parallel (of course!) because the CPU can only process one instruction at a time. If you run the same application on a multi-CPU system, some things may or may not run in parallel, but if the application wasn't designed with parallelism in mind then any speed gains resulting from the additional processor are going to be mostly incidental. Designing for parallelism means (in broad strokes) identifying those tasks in your code that can truly run concurrently, and threading in such a way as to exploit that optimization.
Mind you, I'm not criticizing - you even came close to the same point in your comment. I just wanted to make it clear that multi-threading and parallelism are not interchangeable terms.
|
|
|
|
|
Agreed. Multi-threaded programming might be viewed best as a means of implementing parallelism in an application. Part of my point was that, for a lot of developers, they think the new parallism tools are going to be a 'magic bullet', without actually understanding the concept.
|
|
|
|
|
I agree, but it seems that some people just can't grok it.
I worked with a programmer who thought there was a problem with the ACE threading library - so he decided to replace ACE threading with pthreads. He just couldn't understand how C code and C++ code interacted and ended up dragging around (void* This) pointers around everywhere. Worse, sometimes (This != this). There wasn't anything wrong with ACE threading and we ended up abandoning the branch he was working on and allowing another company to *enjoy* his work.
It seems like many others can't distinguish between threading (which is inherently procedural) and objects. The idea that multiple threads can be calling different methods of the same class, or the same object, or even the same method of the same object is something that people just have problems imagining. These same people seem to have problems with C#'s new "yield return" mechanism.
Amazingly (to me), reentrancy is something that people seem to have no problems with.
Again, I agree. I don't understand why people have these problems. It is very simple to me. Unfortunately, that makes it hard to describe for people. After describing the same thing multiple ways, you want to start sentences with "This is so freakin' simple ....".
Paul
|
|
|
|
|
Paul Reeder wrote: I worked with a programmer who thought there was a problem with the ACE threading library - so he decided to replace ACE threading with pthreads. He just couldn't understand how C code and C++ code interacted and ended up dragging around (void* This) pointers around everywhere. Worse, sometimes (This != this). There wasn't anything wrong with ACE threading and we ended up abandoning the branch he was working on and allowing another company to *enjoy* his work.
Yuck. Fortunately it's been a while since I've had to deal with one of those.
|
|
|
|
|
Paul Reeder wrote: Amazingly (to me), reentrancy is something that people seem to have no problems with.
We need them here.... I spend more time fixing non-reentrant code than I should. One of our programmers programs NOTHING reentrant... 
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
Gary R. Wheeler wrote: There is a substantial learning curve
Why? I heard someone once tell me that all threads take is a mutex to speed them up.... 
But in all seriousness, I think the biggest hurdle is the idea that it can be done and we are capable of doing so. So many programmers have been taught that threads are evil, threading is hard, parallel is 666 in some strange binary code.... We echo so much of what we are taught that it becomes habit: "there is no benefit, why try?" "I can't do it, it is too hard, so why try?"
Once you learn the techniques, and like you said, there is a learning curve, you start to restructure your thoughts into code in parallel forms and make it easier. I had one advantage and that was the last lesson I learned before I dropped out of college was "there are a dozen ways to solve a problem, or implement an algorithm." Knowing that there are many ways to accomplish the same thing, I adapted to parallel much easier than most (or maybe it is because I am "old-school" ).
As such, I use everything at my disposal from GPU massive parallel to OpenMP, to thread building blocks, to my own threads. I've used it all. Lord knows I am no rocket-scientist (I just watch them at a distance ... strange flighty bunch of creatures). Hell, I am a college drop-out and I learned to thread code, so it must not be too hard.... 
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
El Corazon wrote: all threads take is a mutex to speed them up....
I always wondered: what did he-who-shall-not-be-mentioned-even-by-his-initials have against critical sections? If you are synchronizing threads within a process, critical sections are much more lightweight than a mutex. IIRC, they don't even require a kernel transition most of the time, unlike mutexes.
Our applications (multiple processes, many threads per process) use critical sections almost exclusively. The one mutex I'm aware of is used for ensuring only a single instance of the process is running.
|
|
|
|
|
Gary R. Wheeler wrote: I always wondered: what did he-who-shall-not-be-mentioned-even-by-his-initials have against critical sections? If you are synchronizing threads within a process, critical sections are much more lightweight than a mutex. IIRC, they don't even require a kernel transition most of the time, unlike mutexes.
I asked that once. The answer (please put down any liquids and sit down, I will not be held responsible for spewed food or liquid onto expensive monitors, laptops, cell phones or the like... or of personal fainting).... The answer is that Critical Sections are an invention of Microsoft and are not portable. Only mutexes are Unix based and therefore perfect. 
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
El Corazon wrote: The answer is that Critical Sections are an invention of Microsoft and are not portable.
Oh Judas H. Priest. Wrap the freakin' thing in its own class, compile it with mutexes in Unix and with critical sections under Windows. On a bad day (migraine included) I could have such a class working in five minutes, single-handed.
|
|
|
|
|
both linux and windows supports OpenMP and OpenMP supports critical sections. OpenMP is not a Microsoft invention.
logic never works with him.
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
