[Beowulf] scalability
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Chris Samuel csamuel at vpac.orgThu Dec 10 16:33:46 PST 2009
- Previous message: [Beowulf] scalability
- Next message: [Beowulf] scalability
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
----- "Gus Correa" <gus at ldeo.columbia.edu> wrote: > This is about the same number I've got for an atmospheric model > in a dual-socket dual-core Xeon computer. > Somehow the memory path/bus on these systems is not very efficient, > and saturates when more than two processes do > intensive work concurrently. > A similar computer configuration with dual- dual- > AMD Opterons performed significantly better on the same atmospheric > code (efficiency close to 90%). The issue is that there are Xeon's and then there are Xeon's. The older Woodcrest/Clovertown type CPUs had the standard Intel bottleneck of a single memory controller for both sockets. The newer Nehalem Xeon's have HyperTransport^W QPI which involves each socket having its own memory controller with connections to local RAM. This is essentially what AMD have been doing with Opteron for years and why they've traditionally done better than Intel with memory intensive codes. cheers, Chris -- Christopher Samuel - (03) 9925 4751 - Systems Manager The Victorian Partnership for Advanced Computing P.O. Box 201, Carlton South, VIC 3053, Australia VPAC is a not-for-profit Registered Research Agency
- Previous message: [Beowulf] scalability
- Next message: [Beowulf] scalability
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
