On Tue, Sep 29, 2009 at 5:11 PM, Robert Bradshaw <rober...@math.washington.edu> wrote: > > > 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.
+1 > The only downside is that, at least for actively developed projects, > it's nice to use upstream build scripts rather than rolling our own. I think that's always better if 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. > > 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. That's true. For example, the XCode on OS X 10.6 builds 64-bit code by default even if there's no -m64 (unlike on OS X 10.5). Most 64-bit Linuxes have that property too. Solaris and old Mac OS X are the only platforms I can think of that don't. >> 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. There is no -O6 option to GCC. There are three nonzero numbered optimization levels: -O1, -O2, and -O3. Do "man gcc". The optimization options are: -O -O0 -O1 -O2 -O3 -Os "-Os" optimizes for size, but not at the expense of speed. >> 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. The difference between -O2 and -O3 is: " -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops and -fgcse-after-reload options." I think these are not *supposed* to generate invalid assembly code -- if they do, isn't that considered a bug in GCC? Of course there are bugs in GCC, and using aggressive optimization is much more likely to uncover them. -O3 has drawbacks such as potentially larger binaries, cache misses, etc. -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
