On 8/23/07, Adrian Tate <adrian at cray.com> wrote:
>
> Hi Barry
>
> Thanks for your reply.
>
> We will expect to provide the new full releases of PETSc as soon as we
> possibly can. Obviously there is something of a lag because Cray need to
> test, package and release the library, but we'll try to do so with minimal
> delay. Obviously any heads-up you can give us in advance will help reduce the
> lag. With respect to patch versions, it is going to be very difficult for
> Cray to release every
The PETSc development repository is completely open. I recommend you setup
a test build which points to that, along with your release build. That way, when
we release, you will have absolutely nothing to do.
Thanks,
Matt
> Thanks!
> Adrian
>
> -----Original Message-----
> From: Barry Smith [mailto:bsmith at mcs.anl.gov]
> Sent: Monday, August 20, 2007 11:12 AM
> To: Adrian Tate
> Cc: petsc-developers at mcs.anl.gov; petsc-dev at mcs.anl.gov
> Subject: Re: Cray and PETSc
>
>
> Adrian,
>
> Thank you for in the inquiry.
>
>
> On Thu, 16 Aug 2007, Adrian Tate wrote:
>
> > Hello Barry
> >
> > I'm not sure we met in person - I am the lead of the libraries group
> >at Cray. We decided some time ago that our iterative solver strategy
> >would be to leverage PETSc, and to hopefully provide some Cray
> >specific tunings to improve performance of the KSP solvers (largely
> >through our custom sparse BLAS and some parallel tuning for our
> >interconnect). I believe that John Lewis has been in communication
> >with you with respect to the tuning of Sparse BLAS and their
> >integration with the PETSc build.
> >
> >We are however, considering packaging and supplying PETSc along with
> >the scientific library that we provide (libSci). This allows for
> >better integration of our internal kernels and also it means that we
> >are no longer requiring users (including benchmakers and internal
> >users) to build their own PETSc. I see from your online page that
> >doing so is acceptable as long as we use a copyright switch during
> >configure. By applying this switch, do we make our PETSc library
> >unsupported from your perspective?
>
> The GNU copyright code is tiny; it would not effect the usability
> or support of PETSc
>
> > We do not expect to be able to
> >provide anywhere near the degree of support that your team provide,
> >and I was hoping to supply a pre-built library whose users could still
> >seek assistance through your normal support channels - is this
> >realistic?
> >
> Yes.
>
> The two isses that concern us with pre-packaged versions of PETSc are
> 1) keeping up to date on our releases. We generally make two releases
> a year and much prefer that users use the most recently release.
> If they are using an older release it means we are less able to help
> them.
> 2) keeping up to date on our patches. We may make several bug patches
> to each release. Users with a pre-packaged version have trouble keeping
> up with the source code patches we provide.
>
> >
> >
> >
> >
> > Also, I would be interested to know your degree of interest in the
> >Cray-specific modifications that we make - would you prefer those to
> >be channeled back into the PETSc library?
>
> If they involved directly changing PETSc code, we much prefer to get
> it channeled back into the master copy of the source code. Makes it
> much easier to debug user code. If it is auxiliary code, like a faster
> ddot() etc then it is more appropriate to not try to include it.
>
> >Any other comments you have
> >on the way that Cray can contribute to the PETSc project, I would be
> >very glad to hear.
>
> PETSc has a variety of "tuning factors" that could theoretically be
> set optimally for a particular machine, these range from simple things
> like compiler options, to a choice between C and Fortran versions of
> the same code (what we call them Fortran kernels), to different loop
> unrollings (in the inline.h file), even something like PetscMemzero()
> which has five possible forms. Now currently we do not tune these
> or even have a test harness for selecting a good tuning. One thing
> you could/would like to do, is determine good choices for these
> options on your machines. Just as a simple example, on some Linux systems
> the basic libraries are just compiled with the GNU compiler, hence the
> system memset() is not particularly effective. A version compiled of PETSc
> compiled using a "Fortran memset" may be much faster, or Intel provides
> its own _intel_fast_memset() which is better. I've seen a few percent
> increase in performance of entire nonlinear PDE solver applications
> just from using the non-default memset(). [This was specifically on
> an Itanium system, but is likely on other configurations also].
>
>
> Barry
>
>
> >
> >
> >
> > Regards,
> >
> >
> > Adrian Tate
> >
> > ---
> >
> > Technical Lead
> >
> > Math Software
> > Cray Inc.
> >
> > (206) 349 5868
> >
> >
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener
