[petsc-dev] PETSc LU vs SuperLU

[Xiaoye S. Li]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111220/197f92de/attachment.html>