[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Current state of multi-core awareness



Patrick O'Callaghan wrote:
On Fri, Dec 5, 2008 at 4:41 PM,  <dsavage peaknet net> wrote:

Of the thousands of 64-bit F10 applications/tools/utilities, I wonder how
many are aware of and can scale across multiple cores. Has anyone done a
recent survey to see which packages are [not] multi-core aware?

I may be way off-base here, but I would expect very few if any apps
are "multi-core aware". Multiple cores get you better performance when
more than one process needs the cpu, but a single I/O-limited process
isn't going to go any faster. Likewise, single-threaded apps can't do
anything with multiple cores even if they aren't I/O limited.
Specialized parallel-programming apps are a different matter, but how
many of those do we typically see on a desktop?

poc

As stated very well above, it depends on the people who developed the package as to how it uses a CPU, if it is single threaded (and there are a lot of those type out there) then yes, it will plug one core. If it is multithreaded, like say Apache, then, under load you will see it peg all your CPU's/Cores instead of just one. I see this type of behavior on my home server, which has quad core dual Xeon's, and when I stress test HTTP all eight cores start to peak as the load gets higher. As for anything disk I/o intensive, it can be purposeful to have it hog just one core (IE not to build in multi-CPU support) since it improves overall system performance on non I/o intensive programs. Anything package based will be higher on the I/o, and it would be a bad thing to have it hog the entire system processing stuff that has to wait to be written to disk. After all, how many irate users do you see, that are angry because updates are running and taking forever, and they can't use anything else because that package manager is taking forever?


If you want to view what is, and isn't multi-core aware, look at what does, and doesn't use SMP, since that has been around since more than one 'virtual' CPU has been in use (Hyperthreading) and used with multicores.


And on an honest note, I don't really see how package management would require more CPU power, when as a database type program, it would require faster disks to perform better, not more power from the CPU.

~Seann

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]