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