September 2015 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Matthew Knepley 30 Sep '15

30 Sep '15

On Wed, Sep 30, 2015 at 10:29 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > On Sep 30, 2015, at 9:58 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > On Wed, Sep 30, 2015 at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > Matthew Knepley <knepley(a)gmail.com> writes: > > > Richard, this is somewhat subtle since PETSc's inheritance model is > sucky > > > and somewhat broken. Look at > > > the factorization classes, AIJMUMPS etc., before coding anything. > > > > Richard wants to use the MKL implementations of stuff like MatMult and > > MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > > > > It will look like that in the sense that he wants to keep some data > structures and > > not others, and override some functions and not others. AIJMUMPS shows > you > > how to keep things in sync since there are too many places where they > can go > > wrong. Factorization is beside the point. > > No it isn't. We have a special infrastructure for factorizations that > is distinct from making subclasses of mat subclasses. > What matrix subclasses do we have that are not factorizations? Matt > Barry > > > > > Matt > > > > -- > > 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 > > -- 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

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Barry Smith 30 Sep '15

30 Sep '15

> On Sep 30, 2015, at 9:58 AM, Matthew Knepley <knepley(a)gmail.com> wrote: > > On Wed, Sep 30, 2015 at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > Matthew Knepley <knepley(a)gmail.com> writes: > > Richard, this is somewhat subtle since PETSc's inheritance model is sucky > > and somewhat broken. Look at > > the factorization classes, AIJMUMPS etc., before coding anything. > > Richard wants to use the MKL implementations of stuff like MatMult and > MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > > It will look like that in the sense that he wants to keep some data structures and > not others, and override some functions and not others. AIJMUMPS shows you > how to keep things in sync since there are too many places where they can go > wrong. Factorization is beside the point. No it isn't. We have a special infrastructure for factorizations that is distinct from making subclasses of mat subclasses. Barry > > Matt > > -- > 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

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Jed Brown 30 Sep '15

30 Sep '15

Barry Smith <bsmith(a)mcs.anl.gov> writes: >> On Sep 30, 2015, at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> Matthew Knepley <knepley(a)gmail.com> writes: >>> Richard, this is somewhat subtle since PETSc's inheritance model is sucky >>> and somewhat broken. Look at >>> the factorization classes, AIJMUMPS etc., before coding anything. >> >> Richard wants to use the MKL implementations of stuff like MatMult and >> MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > > Jed and Matt, > > Remember Richard actually wrote the subclasses of AIJ for the Cray vector machine so you guys are teaching your grandmother to suck eggs. Where is @shitbsmithsays when you need it? > Barry

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Matthew Knepley 30 Sep '15

30 Sep '15

On Wed, Sep 30, 2015 at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > Matthew Knepley <knepley(a)gmail.com> writes: > > Richard, this is somewhat subtle since PETSc's inheritance model is sucky > > and somewhat broken. Look at > > the factorization classes, AIJMUMPS etc., before coding anything. > > Richard wants to use the MKL implementations of stuff like MatMult and > MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. > It will look like that in the sense that he wants to keep some data structures and not others, and override some functions and not others. AIJMUMPS shows you how to keep things in sync since there are too many places where they can go wrong. Factorization is beside the point. Matt -- 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

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Barry Smith 30 Sep '15

30 Sep '15

> On Sep 30, 2015, at 9:48 AM, Jed Brown <jed(a)jedbrown.org> wrote: > > Matthew Knepley <knepley(a)gmail.com> writes: >> Richard, this is somewhat subtle since PETSc's inheritance model is sucky >> and somewhat broken. Look at >> the factorization classes, AIJMUMPS etc., before coding anything. > > Richard wants to use the MKL implementations of stuff like MatMult and > MatAXPY, not just factorization. So it doesn't look like AIJMUMPS. Jed and Matt, Remember Richard actually wrote the subclasses of AIJ for the Cray vector machine so you guys are teaching your grandmother to suck eggs. Barry

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Jed Brown 30 Sep '15

30 Sep '15

Matthew Knepley <knepley(a)gmail.com> writes: > Richard, this is somewhat subtle since PETSc's inheritance model is sucky > and somewhat broken. Look at > the factorization classes, AIJMUMPS etc., before coding anything. Richard wants to use the MKL implementations of stuff like MatMult and MatAXPY, not just factorization. So it doesn't look like AIJMUMPS.

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Matthew Knepley 30 Sep '15

30 Sep '15

On Tue, Sep 29, 2015 at 7:55 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Richard, > > Sounds reasonable to me. Richard, this is somewhat subtle since PETSc's inheritance model is sucky and somewhat broken. Look at the factorization classes, AIJMUMPS etc., before coding anything. Thanks, Matt > > Barry > > > On Sep 29, 2015, at 5:16 PM, Richard Mills <richardtmills(a)gmail.com> > wrote: > > > > Hi Folks, > > > > It's come up in discussions a few times that, ideally, the burden of > supporting very specific optimizations for complex architectures like > Intel's upcoming Knights Landing MIC processor should be handled as much as > possible by a library like MKL. To take some concrete steps towards this, > I want to add support for using the new sparse BLAS inspector-executor > ("SpMV 2" -- no idea why they called it that) routines that were added in > the recent release (11.3) of MKL. These use an inspector-executor model to > provide some optimized operations (sparse matrix-vector multiplication, > sparse matrix-matrix multiplication, triangular solve, sparse matrix > addition). Those interested can have a look at the documentation here: > > > > https://software.intel.com/en-us/node/590105 > > > > I am thinking that the cleanest way to support this is to add a new > matrix subclass that mostly inherits from MATAIJ (or MATBAIJ), calling the > inspection ("analysis") routines upon matrix assembly finalization and > using the "SpMV 2" routines as appropriate. Then if someone wants to use > the SpMV 2 stuff, they ensure that their matrix ends up as MATMKLSPMV2 (or > whatever better name we come up with). Does this sound reasonable? If you > have a better suggestion, please let me hear it. > > > > --Richard > > -- 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

1 0

Manual figures are messed up
by Stefano Zampini 30 Sep '15

30 Sep '15

I just noticed that Figures 19 and 20 in the manual (current release and master) are messed up. The htmlmap process seems not to work properly. -- Stefano

1 0

Re: [petsc-dev] Adding support for new sparse BLAS inspector-executor routines in MKL
by Barry Smith 29 Sep '15

29 Sep '15

Richard, Sounds reasonable to me. Barry > On Sep 29, 2015, at 5:16 PM, Richard Mills <richardtmills(a)gmail.com> wrote: > > Hi Folks, > > It's come up in discussions a few times that, ideally, the burden of supporting very specific optimizations for complex architectures like Intel's upcoming Knights Landing MIC processor should be handled as much as possible by a library like MKL. To take some concrete steps towards this, I want to add support for using the new sparse BLAS inspector-executor ("SpMV 2" -- no idea why they called it that) routines that were added in the recent release (11.3) of MKL. These use an inspector-executor model to provide some optimized operations (sparse matrix-vector multiplication, sparse matrix-matrix multiplication, triangular solve, sparse matrix addition). Those interested can have a look at the documentation here: > > https://software.intel.com/en-us/node/590105 > > I am thinking that the cleanest way to support this is to add a new matrix subclass that mostly inherits from MATAIJ (or MATBAIJ), calling the inspection ("analysis") routines upon matrix assembly finalization and using the "SpMV 2" routines as appropriate. Then if someone wants to use the SpMV 2 stuff, they ensure that their matrix ends up as MATMKLSPMV2 (or whatever better name we come up with). Does this sound reasonable? If you have a better suggestion, please let me hear it. > > --Richard

1 0

Adding support for new sparse BLAS inspector-executor routines in MKL
by Richard Mills 29 Sep '15

29 Sep '15

Hi Folks, It's come up in discussions a few times that, ideally, the burden of supporting very specific optimizations for complex architectures like Intel's upcoming Knights Landing MIC processor should be handled as much as possible by a library like MKL. To take some concrete steps towards this, I want to add support for using the new sparse BLAS inspector-executor ("SpMV 2" -- no idea why they called it that) routines that were added in the recent release (11.3) of MKL. These use an inspector-executor model to provide some optimized operations (sparse matrix-vector multiplication, sparse matrix-matrix multiplication, triangular solve, sparse matrix addition). Those interested can have a look at the documentation here: https://software.intel.com/en-us/node/590105 I am thinking that the cleanest way to support this is to add a new matrix subclass that mostly inherits from MATAIJ (or MATBAIJ), calling the inspection ("analysis") routines upon matrix assembly finalization and using the "SpMV 2" routines as appropriate. Then if someone wants to use the SpMV 2 stuff, they ensure that their matrix ends up as MATMKLSPMV2 (or whatever better name we come up with). Does this sound reasonable? If you have a better suggestion, please let me hear it. --Richard

1 0