#9533: Update GSL to the latest upstream release (1.14) & permit parallel
building.
----------------------------+-----------------------------------------------
Reporter: drkirkby | Owner: tbd
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.5.2
Component: packages | Keywords:
Author: David Kirkby | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
----------------------------+-----------------------------------------------
Comment(by drkirkby):
Replying to [comment:30 leif]:
> I finally found out what we have to do to make GSL use ATLAS's CBLAS in
Sage: '''Nothing! 8D'''
>
> (A closer look at {{{$SAGE_ROOT/devel/sage-main/module_list.py}}}
helped. I hope other ''Sage packages'' that require CBLAS will also link
with {{{libcblas.*}}}, not {{{libgslcblas.*}}}.)
>
> The only thing we could (but perhaps shouldn't) do is run GSL's
testsuite with ATLAS's CBLAS library instead.
> But since GSL's implementation is used as a fall-back in Sage, we should
leave it as is, and - if at all - only do an ''additional'' run of the
testsuite with ATLAS's CBLAS library. (But I've not yet figured out how
simple that is; in worst case we'd have to {{{make clean}}}, {{{make}}}
again with {{{LDFLAGS="$LDFLAGS -L$SAGE_LOCAL/lib -lcblas -latlas"}}} and
then {{{make check}}}.)
I think at this point in time, just merging the updated GSL is sufficient.
That was the aim of the ticket.
Other tasks, '''if''' we tackle them, should be on another ticket.
There are three related issues I am aware of
* Sage ships with {{{blas-20070724.spkg}}} which is a BLAS library, and
according to François Bissey, this is unnecessary, as we have ATLAS.
http://groups.google.co.uk/group/sage-devel/msg/a75a7e796a5c3a91
* We should be updating ATLAS. It was agreed to update ATLAS, and I said
I would do it, but it far from a trivial affair. I need to discuss with
Carl Witty how to build this in parallel. ATLAS takes about 8-10 hours to
build in 't2' as there are no tuning parameters for that processor.
* I've got no idea what GSL is used for in Sage. If it's just special
functions, which is quite possible, then its pointless worrying about it
anyway.
My biggest priority now is to get Sage working properly on !OpenSolaris -
it builds, but just dumps core as soon as one starts it. Hence I want to
be able to verify the different parts of Sage are working - I'm less
concerned if they are fully optimised.
If I believe the tools on Solaris, starting Sage, before one gets to the
{{{
sage:
}}}
prompt, there is already several memory leaks. I see the quality control
issues in Sage (doctest, self-tests, memory leaks), more important than
addling extra functionality, or speeding Sage up.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9533#comment:32>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
