On Wed, Apr 7, 2021 at 5:47 PM Scott Kruger <kru...@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 kru...@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/>