So, to do this, would I want to rebuild PETSc using a vendor compiler like Intel or PGI? Are there other performance benefits to building PETSc with a vendor compiler such as Intel or PGI besides the benefit of linking with vendor blas?
Xiaoye S. Li writes: > For SuperLU, MUMPS, UMFPACK etc, you need to link with a good BLAS, like > MKL you mentioned. The internal algorithms exploit dense matrix > sub-blocks, and good BLAS usually make a difference. For very sparse > problems, the above packages may not help, since there is not much blocking > to exploit, and the overhead of trying to find the blocks cannot be easily > offset. > > Sherry > > > On Tue, Dec 20, 2011 at 7:28 AM, Dave Nystrom <dnystrom1 at comcast.net> > wrote: > > > I have been comparing sequential SuperLU on one of my linear solves versus > > PETSc LU. I am finding SuperLU to be a little over 2x slower than PETSc > > LU. > > I was wondering if this is due to SuperLU not being tuned to my problem or > > if > > the PETSc LU algorithm performance is expected to be superior to that of > > SuperLU in general. I did play around with the reordering options for > > SuperLU but did not find anything superior to the defaults. I was also > > wondering if building PETSc and its external packages with another compiler > > such as PGI or Intel might result in higher performance in this regard. Or > > whether using a vendor blas like MKL would speed up SuperLU. Or perhaps > > the > > interface of SuperLU to PETSc results in some extra data copying that is > > the > > difference. > > > > Does anyone have any idea why SuperLU might be that much slower than PETSc > > LU? > > > > I also tried spooles and that was just a little slower than PETSc LU. And > > I > > tried MUMPS and that seg faulted after my problem had been running over an > > hour. This particular problem was running for less than 3 minutes with > > PETSc > > LU. > > > > I would be interested in any suggestions of things to try to speed up my LU > > solve with either PETSc or any of the external packages. Right now, I'm > > just > > doing serial, single node calculations. > > > > Thanks, > > > > Dave > >
