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.

In reply to Re: WorkCrew threading by mr_mischief
in thread WorkCrew threading by FFRANK

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.