<div dir="ltr"><div dir="ltr">On Wed, Apr 7, 2021 at 5:47 PM Scott Kruger <<a href="mailto:kruger@txcorp.com">kruger@txcorp.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-04-06 14:44, Matthew Knepley did write:<br>
> > > Does spack have some magic for this we could use?<br>
> > ><br>
> ><br>
> > spack developed the archspec repo to abstract all of these issues:<br>
> > <a href="https://github.com/archspec/archspec" rel="noreferrer" target="_blank">https://github.com/archspec/archspec</a><br>
> <br>
> <br>
> I do not love it. Besides the actual code (you can always complain about<br>
> code),<br>
> they do not really do any tests. They go look in a few places that data<br>
> should be.<br>
> We can do the same thing in probably 10x less code. It would be great to<br>
> actually<br>
> test the hardware to verify.<br>
> <br>
<br>
My impression is that the current project is languishing because they<br>
are focusing on the spack side right now.   But if this is the project<br>
that is the ECP-annointed solution, then it has the best chance of<br>
succeeding through sheer resources.   <br></blockquote><div><br></div><div>Maybe this will end up eventually being good. However, in my lifetime at DOE, funded</div><div>projects are usually the best indicator of what not to do.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The thing I like the best is that having a stand-alone project to handle<br>
these issues is a real forehead-slapper (i.e., "why didn't I think of<br>
that?!").  Todd Gamblin has stated that the goal is to allow vendors to<br>
contribute because it will be in their interest to contribute.  This<br>
should have been done years ago.<br>
<br>
Regarding whether we could do better:  Now would actually be a good time<br>
to contribute while the project is young, but I don't have the time<br>
(like everyone else which is why this is a perennial problem).   It<br>
would also be a good time to create a separate project if this one is<br>
too annoying for folks.  In general, like spack, they have done a good<br>
job on the interface so that part is important.<br>
<br>
Scott<br>
<br>
<br>
<br>
<br>
>   Thanks,<br>
> <br>
>      Matt<br>
> <br>
> <br>
> > This is a *great* idea and eventually BuildSystem should incorporate it as<br>
> > the standard way of doing things; however, it is been focused mostly on<br>
> > the CPU issues, and is still under active development (my understanding<br>
> > is that the pulling it out of spack and getting those interop issues<br>
> > sorted out is tangled up in how spack handles dependencies and<br>
> > compilers).  It'd be nice if someone would go in and port the Kokkos gpu<br>
> > mappings to archspec as there is some great knowledge on these mapping<br>
> > buried in the Kokkos build system (not volunteering); i.e., translating<br>
> > that webpage to some real code (even if it is in make) is valuable.<br>
> ><br>
> > TL;DR:  It's a known problem with currently no good solution AFAIK.<br>
> > Waiting until archspec gets further along seems like the best solution.<br>
> ><br>
> > Scott<br>
> ><br>
> > P.S. ROCm has rocminfo which also doesn't solve the problem but is at<br>
> > least sane.<br>
> ><br>
> <br>
> <br>
> -- <br>
> What most experimenters take for granted before they begin their<br>
> experiments is infinitely more interesting than any results to which their<br>
> experiments lead.<br>
> -- Norbert Wiener<br>
> <br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a> <<a href="http://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">http://www.cse.buffalo.edu/~knepley/</a>><br>
<br>
-- <br>
Scott Kruger<br>
Tech-X Corporation               <a href="mailto:kruger@txcorp.com" target="_blank">kruger@txcorp.com</a><br>
5621 Arapahoe Ave, Suite A       Phone: (720) 466-3196<br>
Boulder, CO 80303                Fax:   (303) 448-7756<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>