in reply to My experience with Perl threading and the reason I think that I have rushed a little bit

I concur with aragorn, solve this problem with select rather than threads. Question: How many processors does the computer you run your thread code on have? If it's just one, then the only way your code can achieve speed-up is if there is potential waiting due to I/O.

I too have experience with writing real threads with C code and the pthread.h library (see Solved N-Queens (warning: C code ahead). My computer at home is Dual processor and the computers i used at school had Dual and Quad processors. We saw true speed-up, even the occasional super-linear speedup when we threaded our programs. I think that a lot of people think that by threading your program, it just magically "speeds up." This is simply not true, especially if they are only using a One Proc Box (apologies to Sammy Hagar). Speed up happens on a One Proc Box when processes have to wait on things like on I/O, and select is a good (yet hard to understand) solution for this.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
  • Comment on Re: My experience with Perl threading and the reason I think that I have rushed a little bit

Replies are listed 'Best First'.
Re: Re: My experience with Perl threading and the reason I think that I have rushed a little bit
by pg (Canon) on Jan 07, 2004 at 16:14 UTC

    I only have one CPU, so I was not expecting any performance improvement. Instead I expected to lose some performance as all those swapping going on, however because Perl's thread is very "heavy", the downgrade is bigger than one's experience.

    The real thing I expected was, the near-equal response to multiple HTTP messages, but sadly that didn't happen. My guess is that it has something to do with Perl's current scheduling model.

    With select() and some careful thinking, I get much better results.

    Yeah, you are right.