[petsc-dev] -with-kokkos-cuda-arch=AMPERE80 nonsense

[Matthew Knepley]

On Wed, Apr 7, 2021 at 5:47 PM Scott Kruger <kruger at txcorp.com> wrote:

> On 2021-04-06 14:44, Matthew Knepley did write:
> > > > Does spack have some magic for this we could use?
> > > >
> > >
> > > spack developed the archspec repo to abstract all of these issues:
> > > https://github.com/archspec/archspec
> >
> >
> > I do not love it. Besides the actual code (you can always complain about
> > code),
> > they do not really do any tests. They go look in a few places that data
> > should be.
> > We can do the same thing in probably 10x less code. It would be great to
> > actually
> > test the hardware to verify.
> >
>
> My impression is that the current project is languishing because they
> are focusing on the spack side right now.   But if this is the project
> that is the ECP-annointed solution, then it has the best chance of
> succeeding through sheer resources.
>

Maybe this will end up eventually being good. However, in my lifetime at
DOE, funded
projects are usually the best indicator of what not to do.

   Matt


> The thing I like the best is that having a stand-alone project to handle
> these issues is a real forehead-slapper (i.e., "why didn't I think of
> that?!").  Todd Gamblin has stated that the goal is to allow vendors to
> contribute because it will be in their interest to contribute.  This
> should have been done years ago.
>
> Regarding whether we could do better:  Now would actually be a good time
> to contribute while the project is young, but I don't have the time
> (like everyone else which is why this is a perennial problem).   It
> would also be a good time to create a separate project if this one is
> too annoying for folks.  In general, like spack, they have done a good
> job on the interface so that part is important.
>
> Scott
>
>
>
>
> >   Thanks,
> >
> >      Matt
> >
> >
> > > This is a *great* idea and eventually BuildSystem should incorporate
> it as
> > > the standard way of doing things; however, it is been focused mostly on
> > > the CPU issues, and is still under active development (my understanding
> > > is that the pulling it out of spack and getting those interop issues
> > > sorted out is tangled up in how spack handles dependencies and
> > > compilers).  It'd be nice if someone would go in and port the Kokkos
> gpu
> > > mappings to archspec as there is some great knowledge on these mapping
> > > buried in the Kokkos build system (not volunteering); i.e., translating
> > > that webpage to some real code (even if it is in make) is valuable.
> > >
> > > TL;DR:  It's a known problem with currently no good solution AFAIK.
> > > Waiting until archspec gets further along seems like the best solution.
> > >
> > > Scott
> > >
> > > P.S. ROCm has rocminfo which also doesn't solve the problem but is at
> > > least sane.
> > >
> >
> >
> > --
> > 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
> >
> > https://www.cse.buffalo.edu/~knepley/ <
> http://www.cse.buffalo.edu/~knepley/>
>
> --
> Scott Kruger
> Tech-X Corporation               kruger at txcorp.com
> 5621 Arapahoe Ave, Suite A       Phone: (720) 466-3196
> Boulder, CO 80303                Fax:   (303) 448-7756
>


-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20210407/e141cc3b/attachment.html>