Re: WorkCrew threading

[mr_mischief]

What BrowserUk said, plus the fact that the programmer, you, has to deal with coordinating ten threads instead of just getting the work done in one.

On the bright side, if you develop it on one processor then move it to ten, you should see a nice speedup assuming the job is high enough priority that it gets time slices on all ten processors, your coordination between threads as programmed by you is lightweight enough, and the contexts switches don't eat up all the differences.

On the dark side, something so simple, if it's not doing this with a huge, huge array, would probably just be scheduled all on one or two processors on most SMP machines anyway because other jobs would be given higher priority (unless you have a ten processor box just lying around for testing).

Really, you should see some speedup, in theory, well before ten processors. The overhead inherent in the thread coordination plus the overhead of the context switches in the system mean you may not necessarily see any improvement on a two-processor box, though. I think I could safely say it should be faster to do it as ten threads than as one by the time you get to four processors, but the ten threads wouldn't necessarily be any faster there than four threads.

In other words, welcome to the great unknown of multi-threaded programming on multi-processor machines. There are truths to be told, such as what BrowserUk told you about overhead taking away performance on the single-processor box. Beyond that, though, there's theory and practice.

Take a look at any of the recent dual-core and quad-core CPU benchmarks out on the hardware enthusiast websites with the more recent games. You'll see that the chip companies don't even pretend that twice the cores at the same speed is going to equal twice the work. Then the reviewers and benchmarkers go on to say which benchmarks make more or less use of the multiple cores.

I don't mean to scare you away from threads, but they are no panacea. They don't, for example, deal well with being split across machines. Multi-process projects that use IP networking do. Threads don't necessarily mean better speed on a single computer, but they can. The best reasons to use threads are that they fit the design of the project well and that they can take advantage of particular architectures when run on those architectures. Of course, using them just to learn to use them better is a good goal, too.