On Tue, Sep 29, 2009 at 3:36 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > > Robert Bradshaw wrote: >> On Sep 29, 2009, at 11:55 AM, David Joyner wrote: >> >>> Thanks for working on this. >>> >>> What more needs to be tested? The install went fine on an intel >>> macbook running 10.6. >>> >>> Maybe Robert Bradshaw should comment on it, since he wrote >>> rubik.py? >> >> OK, I'll bite. >> >> I simply took the three individual packages and put them all into the >> same spkg. I'm no build guru, so I mostly left the make scripts, etc. >> as they were, and they compiled and worked on all (at the time) >> supported platforms. I am sure the authors were not targeting >> Solaris, let alone their compiler, or maybe not even anything beyond >> their own personal machines. The makefiles have since been edited >> many times, looks like you were careful so hopefully all issues are >> finally sorted out. >> >> I do have to ask, fortran flags? I know there's no fortran in there. >> Also, the lack of -m64 doesn't imply 32-bit, does it? And why O2 >> rather than O3? >> >> - Robert > > Hi Robert, > > thank you for biting! > > First I have had about 5 pints of beer tonight, so bear this in mind! > > I've tried to create a spkg-install which will work properly on almost > any package, with the hope of providing some measure of standardisation. > At the minute, lots of different spkg-install's exist, and some seem > pretty poor to me. I think it is better if we could have a basic > spkg-install, which set up most things, then the producer of a .spkg > just needed to consider specific issues with their package. > > As such, I've set all flags, including those for Fortran, even when not > needed. The extra few bytes of code does no significant harm. If the > package does not use Fortran, then it will ignore the Fortran flags.
Why not set all that stuff *before* spkg-install is ever called? Say in the script sage-env? Just curious. William > > The problem with creating a spkg-install with a subset of things set, is > that the subset needs carefully testing for each package. My version > might waste a couple of KB bytes, but it is safe. > > So I have tended to write spkg-install's in such a way that they should > work with any package. > > Minh asked me the other day to write this up, though I chose not to just > now, as I am not convinced my latest version is as good as possible. > > A lack of the ability to add -m64 does on some platforms mean it is not > possible to build 64-bit code. Solaris is such a platform. All Solaris > machines made in the last 10 years or so are 64-bit, but Sun still by > default build binaries 32-bit. This is sensible, as pointers are > smaller, more can fit in the cache etc. There are certainly > disadvantages to 64-bit code. Likewise I believe on OS X, The fact > SAGE64 was not used in rubiks, made it impossible to create a 64-bit > binary rubiks on OS X. > > Since the aim is to ultimately produce a Sage capable of 64-bit, then > the SAGE64 variable needs to be handled correctly. > > One could reasonably argue that some part of Sage benefit from 64-bit, > and others do not. I know at one point Mathematica's kernel on Solaris > was 64-bit, but the front end was 32-bit, simply since Wolfram Research > rightly realised there were disadvantage, and no significant advantages > to having a 64-bit front end. > > But my belief is that Sage should be build either 32-bit or 64-bit, and > not a mix of the two. (If others feel differently, say so). > > If we are going to mix the two, then there needs to be a big discussion > about what bits of Sage are to be 64-bit and what bits are to be 32-bit. > It's easier to make all Sage 32-bit or all Sage 64-bit in my opinion. > That means all packages must consider the variable SAGE64. > > As for -O2 vs -O3, the spkg-install says: > > # Add a sensible default optimisation flag. Change if necessary. > OPTIMIZATION_FLAGS="-O2" > > Without a lot of care taken to > > * Look at the code > * Check exactly what -O3 does for every compiler > * Extensive testing > > I don't think it is safe to assume -O3 will be safe and not create a > problem. > > > One of the troublesome packages I noticed when testing with Sun Studio > is tachyon, which uses -O6. > > http://sagetrac.org/sage_trac/ticket/7069 > > It's not the -O6 which is causing the Solaris problem, though I do think > -O6 is unwise. The fact that the tachyon.spkg ignores CC and uses gcc > anyway, makes me believe the code is not well thought out. Therefore I > suspect there has not been extensive testing to prove -O6 is safe. > > > > The problem with the more aggressive optimisations is that they can lead > to inaccurate assembly code, as compiler makes assumptions which are not > true. I believe at -O2, the assembly code will be ok. I don't think that > is necessarily true at -O3. While -O3 might be safe, unless someone is > going to test it, then I think its unwise to use -O3. > > > Dave. > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
