Re: Fedora SMP and 12 core cpu's

To be honest your bigger problem is finding enough application
parallelism and enough parallel user space apps. That and memory or I/O
bandwidth on servers.

The kernel will run on supercomputers with over 1000 processors. Not all
workloads are handled well at that scale so if you threw 1000 random user
instances on it you wouldn't get great results in a lot of cases.

On a desktop its instructive to measure how many processor cores ever end
up running at once. About the only time an 8 core box seems to use all
cores at once is compiling kernels.

On a server you've got more chance as you've often got a lot of work
hitting the box from multiple sources, but in many cases then the
bottleneck ends up being I/O and memory bandwidth unless you've got a
board with separate RAM hanging off all the CPUs, and you spent real
money on the I/O subsystem.

This is actually one of the things that really hurt certain workloads.
There are some that simply don't parallelise and the move to many cores
and to clusters has left them stuck.

Alan
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

Relevant Pages

  • Re: Fedora SMP and 12 core cpus
    ... That and memory or I/O ... bandwidth on servers. ... The kernel will run on supercomputers with over 1000 processors. ... On a desktop its instructive to measure how many processor cores ever end ...
    (Fedora)
  • Re: Not enough parallelism in programming
    ... >> very poor use of parallelism and low scalability. ... all experience is that the way to use 2-4 cores ... Let us say that we change the I/O design ...
    (comp.arch)
  • Re: The Emperors new clothes
    ... >>> Apps that make limited explicit use of parallelism may ... transistors is to simply add cores. ... And remember that what an extremely talented programmer can do is, ... barrel of sewage, you get sewage. ...
    (comp.arch)
  • Re: Speed wars 3: OCaml, F#, Clojure, Pascal
    ... no one else was able to reproduce your results running your OCaml ... Florian only ran his parallel version on 2 cores before concluding ... that GHC's support for scalable parallelism was superb. ... You have concluded that Haskell performs "very well" despite the fact ...
    (comp.lang.functional)
  • Re: Multiple Threads vs. Asynchronous IO
    ... To get the most out of your system, the number of threads should equal the number of cores available. ... Hardly anyone these days has a dedicated system, however; few interesting tasks are dominantly compute bound; and "well optimized" means that the synchronization and data sharing are perfectly designed, not just that you've built with the right compiler options. ... If your threads are going to block (whether on I/O or on unnecessarily loose synchronization and predicates), you may well gain performance with more threads that can take up some of the slack. ... It'll almost never be best for a tightly coupled compute bound job, though; you're probably swamping the parallelization of computation with generalized synchronization paths through the thread pool. ...
    (comp.programming.threads)