Skip to main content
12 events
when toggle format what by license comment
Sep 15, 2012 at 15:47 comment added Pedro @JedBrown: No, but a peer-reviewed paper showing that method M can solve problem X faster than methods N, P, and Q, can be interpreted as M being better than N, P, and Q for that problem. It's hard to compare the Elemental results with those in the PLASMA paper, since the number of CPUs and the problem size differ quite extremely. For the Cholesky decomposition at 10k rows, the only result in common, Elemental is as fast as ScaLAPACK on 8192 cores. PLASMA is 2.5x and 1.5x faster on 16/32 cores respectively.
Sep 15, 2012 at 15:27 comment added Jed Brown @Pedro Someone publishing that they can solve problem X using method M should not be interpreted as the authors claiming that M is the best way to solve problem X. ;-) The Elemental paper reaches a higher fraction of peak using 8x more cores on a smaller problem (that uses less than 1% of memory). From their experience, the larger problem sizes easily deliver high fractions of peak, but due to cubic complexity, burn through allocations. We may get access to run Elemental on the Altix so we can provide your desired direct comparison.
Sep 15, 2012 at 13:19 comment added Pedro @JedBrown: This is straying from the original question, but here is a comparison of PLASMA with LAPACK (using MKL/ESSL's threaded BLAS), ScaLAPACK (using MPI) and Intel/IBM's own threaded math libraries on two different 16/32 core Intel/Power architectures. PLASMA beats them in almost all cases. Unless you can point me to a direct comparison with a different parallel library that says otherwise, I won't be convinced that task-based parallelism is a bad idea (in this case).
Sep 15, 2012 at 12:46 comment added Jed Brown @Pedro You claimed that my point 1 was refuted by MAGMA (or PLASMA?), which would normally imply a comparison or demonstrable optimality. Comparing to MKL is contrived because MKL does not target that environment. Vendor BLAS implementations systematically under-performed prior to Goto demonstrating how to use L2 effectively. If back then, we applied the same reasoning you seem to be using here, we would have come to some false conclusions. As for the FMM paper, most of Rio's work has been with ultra-scalable distributed memory implementations, which the quark-based paper does not compare to.
Sep 15, 2012 at 11:22 comment added Pedro @MattKnepley: I know, but the particle-mesh and mesh-particle interpolations, which take a significant chunk of the computation time, are also just short-ranged interactions. The rest is then usually just FFTs or sparse linear algebra. There are, of course, tree-codes, but this also already appears to have been done with QUARK.
Sep 15, 2012 at 11:19 comment added Pedro @JedBrown: I don't know what "successful" or "fair comparison" you're quoting, as I never used those terms. Again, with regards to MAGMA, it's still roughly twice as fast as Intel's MKL. And again, I'd like to reiterate that the question is not whether such approaches are good or not, but if there are software packages out there in which they have been used.
Sep 14, 2012 at 13:54 comment added Matt Knepley Pedro, most physics has a long range component, so particles are coupled with an update which is subject to the surface-to-solume effect above (PPPM, vortex particle, etc)
Sep 14, 2012 at 13:35 comment added Jed Brown 3. I don't know what "fair comparison" you intend to be citing, but PLASMA only gets about 25% of peak FPU (e.g. slide 5 of hpcgarage.org/cscads2012/Luszczek-UTK-PowerTools.pdf) which would be upublishably bad for the same operation in distributed memory where at least 70% of peak would be expected. Dense linear algebra is an FPU-bound case that I specifically cited as a possible exception, but despite the enormous matrix sizes, PLASMA is obviously far from being FPU-bound.
Sep 14, 2012 at 13:30 comment added Jed Brown 1. There are a handful of projects using these systems, but I don't think the approach can be considered "successful". 2. The dependencies are still overlapping in shared memory. Look at the way tcmalloc or the Linux kernel makes threads more independent to avoid bottlenecks such as synchronization through atomics. Shared address space does not imply you should operate as though you had uniform memory or that you should consider atomics to be inexpensive.
Sep 14, 2012 at 8:23 comment added Pedro The question, in any case, was a different one... Do you know of any scientific computing software projects that use these approaches?
Sep 14, 2012 at 8:22 comment added Pedro I may be misunderstanding your answer, but the first point is exactly the opposite of what Buttari, Kurzak, Dongarra and others have shown with MAGMA, a task-based shared-memory library for dense linear algebra... Also, in your second point you refer to overlapping data, i.e. ghost values, and the surface-to-volume ratio, but these are a hold-over from distributed-memory domain decomposition schemes. I myself work with such methods for particle-based codes, and I get much better performance than MPI-based parallel implementations.
Sep 13, 2012 at 21:05 history answered Jed Brown CC BY-SA 3.0