On Sep 29, 2009, at 3:36 PM, Dr. David Kirkby 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. > > 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. Sounds like something that could be globally useful, rather than having separate logic inside each spkg. Especially if it gets improved and updated over time. (On the other hand, I'm not sure how much this script overlaps with the use of autoconf...) The only downside is that, at least for actively developed projects, it's nice to use upstream build scripts rather than rolling our own. > 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. I was under the impression that some platforms build 64-bit code by default even if there's no -m64 flag, i.e. the laack of SAGE64 does not imply 32-bit. > 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. I had the impression that -O3 was generally the most aggressive safe level (and usually when people have issues due to optimization, they have to tune it down to -O0 or sometimes -O1 to get them to go away). Of course, this is all well out of my area of expertise, so thanks for the your comments. - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
