There are some posts about this topic some time ago. Planewave codes use a lot of memory bandwith, so an Intel quadcore is not much faster than a dual core on the same mainboard, because the memory bus becomes the bottleneck of the system, and all core share the same bus.
Cheers Marcel On Fri, 8 Feb 2008, Axel Kohlmeyer wrote: > On Fri, 8 Feb 2008, ambavale sagar wrote: > > > sagar, > > AS> Is multi (quad) core processor more efficient than single core for our > > please clarify what you mean by "efficient". > more throughput for the same money, faster execution, > better utilization of the cpu, less room needed for > a given computational capability? > > AS> abinitio calculations? How efficiently multi-threading is done while > AS> working with serial version of code on multicore machine? > > it is a common misconceptions that you need to use multi-threading > to take advantage of multicore cpus. the vendors of those cpus > are somewhat promoting it, because it is simpler to add multi-threading > to a code than to parallelize it completely, and also because > their new cpus don't have any advantage over the older ones without > paralleization. fortunately, the methods used in quantum espresso > are well parallelizable and the code offers multiple levels of MPI > parallelism which i found to be almost always more efficient than > using OpenMP (and thus multi-threading). even more so, QE does not > support OpenMP (only indirectly via threaded BLAS/LAPACK libraries). > > depending on your hardware, problem set size and compiler/library > combination, you can get a speedup of roughly 2.5x to 3.5x from > a quad core cpu over a corresponding single core. when using multiple > nodes via a network, however, the speed and the latency of the > network (and the options of parallization, i.e. if you can parallelize > over k-points or not) start to matter and can make it all very > confusing. > > in the end, apart from a few general observations, there is no other > way to get a definite answer than running tests with representative > input files. > > cheers, > axel. > > p.s.: this brings up the question again, that we should compile a > list of such typical inputs and run them on mutually available > machines so people can see what to expect.... > > AS> > AS> Thanx. > AS> > AS> ? > AS> > AS> Sagar K. Ambavale > AS> > AS> PhD student, > AS> > AS> The M.S. University of Baroda, > AS> > AS> India > AS> > AS> > AS> > ________________________________________________________________________________ > AS> 5, 50, 500, 5000 - Store N number of mails in your inbox. Click here. > AS> > > -- > ======================================================================= > Axel Kohlmeyer akohlmey at cmm.chem.upenn.edu http://www.cmm.upenn.edu > Center for Molecular Modeling -- University of Pennsylvania > Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323 > tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425 > ======================================================================= > If you make something idiot-proof, the universe creates a better idiot.
