It has to do with how many threads the program is able to start. If the
program can work with multiple threads in parallel then it will use both
CPU's. However, that is generally a function of the scheduler in the
kernel to decide where each process (or thread) will run and when. So I
would think that compressing would be hard to parallelize. On the other
hand you can probably compress and write an image to the CDR at the same
time without much problems. Or maybe even runt setiathome and not cause
trouble.
> -----Original Message-----
> From: Steve Philp [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 17, 1999 12:00 AM
> To: [EMAIL PROTECTED]
> Subject: [expert] SMP newbie
>
>
> Hello all!
>
> I've taken the plunge and picked up a pair of Celeron 400's
> and an Abit
> BP6 board. This is my first foray into the wild yonders of SMP, so
> forgive my naive questions.
>
> I was under the impression that since the kernel and libc libraries
> natively support SMP, applications would automatically make
> use of both
> processors without intervention. I'm wondering whether I was
> incorrect.
>
> As a test, I ripped an audio track from a CD and started
> 'notlame' (also
> tested 'bladeenc' with similar results) to encode the wav file. Using
> top, the encoding process never used more than 50% of CPU time. This
> makes me think that it's only making use of one processor. Even using
> 'nice -19 <blah>' never yielded much more than 50% CPU.
>
> Was I naive to think that applications "auto-magically" benefit from
> SMP? Anyone know of an MP3 encoder that will make use of the second
> processor?
>
> Thanks for any tips and tricks!
>
> --
> Steve Philp
> Network Administrator
> Advance Packaging Corporation
> [EMAIL PROTECTED]
>
