[mesa-users] alternative blas, lapack

[Bill Paxton]

On Mar 11, 2015, at 11:42 AM, Amber Lauer wrote:

> So if I understand you guys correctly, you're saying it's probably not worth it?
> 

Hi Amber,

Right; probably not worth it.  I'm happy to hear about anything that will improve the efficiency -- but this particular approach has been gone over more than once.  Our current implementation strips down the relevant routines to a bare minimum (dropping checking argument validity, for example, since the checks can be made at a higher level in the code rather than repeated over and over in an inner loop).   And some of the optimizations like loop unrolling that were critical 20 years ago are becoming counter productive with modern machines having wide vectorization capabilities.  

-Bill




> On Sun, Mar 8, 2015 at 11:09 PM, Francis Timmes <fxt44 at mac.com> wrote:
> silly me.
> 
> upon reflection, drop-in lapack or blas “replacements” are doomed to have a
> small effect because many of the routines used in mesa/star are customized
> (e.g., the my_* modules in mesa/include/mtx_solve_routines.inc) for improved
> performance  with mesa (e.g., lower calling overhead, simd directives,  etc).
> 
> i’m posting this in case someone decided to follow up on the experiment ...
> 
> fxt
> 
> 
> 
> 
> > On Mar 6, 2015, at 11:44 PM, Francis Timmes <fxt44 at mac.com> wrote:
> >
> > i gave this a try. editing $MESASDK_ROOT/bin/mesasdk_*_link to use
> > the os x accelerate framework was easy, fixing the build failures
> > caused by differences from the fixed test_output file in mtx/test,
> > num/test, net/test, and gyre/test was less fun.
> >
> > i ran a 30 msun 21 isotope net starting from the pre-main-sequence
> > for 2000 steps (midst core oxygen burning). no pgstar output, but
> > otherwise my stock setup for massive stars. on a 4 core laptop
> > a normal mesa build took 740 averaged over three runs.
> > using the accelerate framework took 712 s averaged over three runs.
> >
> > so in this specific case the speedup was ~3%.
> > of course, maybe i messed something up, your milage may vary, and
> > two dozen other caveats why this is not a definitive number.
> >
> > fxt
> >
> >
> >
> >> On Mar 6, 2015, at 8:07 AM, Richard Townsend <townsend at astro.wisc.edu> wrote:
> >>
> >> Good question — and to my knowledge, the answer is no. The blas and lapack libraries bundled with the SDK are the reference versions, and as such could be appreciably slower than tuned libraries (e.g., ATLAS). This is for obvious reasons: tuned libraries are architecture-specific, and given the hardware heterogeneity of x86_64 platforms there is  no meaningful default option.
> >>
> >> If you happen to have tuned libraries on your system, you can easily make the SDK use them by editing the $MESASDK_ROOT/bin/mesasdk_*_link scripts to emit the appropriate linker commands. I’ve used this in the past to link to the OS X Accelerate framework.
> >>
> >> cheers,
> >>
> >> Rich
> >>
> >>> On Mar 6, 2015, at 12:41 AM, Amber Lauer <alauer1 at tigers.lsu.edu> wrote:
> >>>
> >>> Is there some place where the relative merits of external vs SDK libraries for the math functions are discussed?
> >>>
> >>> --
> >>> Amber Lauer. M.S. Physics
> >>> PhD Student,
> >>> Dept. of Physics & Astronomy,
> >>> Louisiana State University
> >
> 
> 
> 
> 
> -- 
> Amber Lauer. M.S. Physics
> PhD Student,
> Dept. of Physics & Astronomy,
> Louisiana State University
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/_______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150311/f9d1fb7a/attachment.html>