Peter Jeremy wrote: > On 2009-Dec-29 23:57:13 +0000, "Dr. David Kirkby" <david.kir...@onetel.net> > wrote: >> Peter Jeremy wrote: >> Yes it does. And I can understand why, since for 99% of programs, there is >> no >> advantage to 64-bit, but some disadvantages (larger pointers, let fit in >> cache >> etc). > > OTOH, programs doing multi-precision integer math should benefit from > 64-bit arithmetic - and I would expect that at least some parts of > Sage would benefit from this. > > The crucial advantage of 64-bit is (effectively) unlimited address > space - if you need to manipulate more than ~2GB data then 64-bit > is the only way to go.
I guess I did not make it clear, but I was implying that Sage was a program in the 1% category where there are significant advantages to 64-bit. > x86 vs x86_64 isn't as clearcut because the x86 architecture is so > badly designed - the relatively small number and lack of orthogonality > of registers and lack of a 16-bit relative addressing mode makes the > code relatively large for a 32-bit CISC architecture (it's close in > size to the RISC SPARC). > against it. > >> I would have thought the only advantage of a 32-bit would be the >> fact that gcc is less buggy. > > Whilst this may be true for SPARC, I haven't seen any sign of it with x86_64. Fair enough - I've more experience of SPARC than of x86. I had forgot one other advantage of supporting 32-bit, in that Open Solaris does run on 32-bit hardware. I can imagine there are a fair number of PCs in use with 32-bit processors, but I would have thought anyone installing Open Solaris and wanting to build Sage, would have used a 64-bit machine. If you have a 64-bit system, Open Solaris will boot a 64-bit kernel by default. It might be possible to change that, but I doubt many will want to. We do not have the resources to test on many systems. The OpenSSL libraries are building by default in 64-bit mode on my Sun Ultra 27: ------------------------------------------------ bash-3.2$ ./config Operating system: i86pc-whatever-solaris2 Configuring for solaris64-x86_64-gcc Configuring for solaris64-x86_64-gcc <SNIP> making links in fips/hmac... fips_hmactest.c => ../../test/fips_hmactest.c generating dummy tests (if needed)... Configured for solaris64-x86_64-gcc. bash-3.2$ ------------------------------------------------ My attempts to chose a different target from the default (solaris-x86-gcc seemed the only semi-plausible alternative), resulted in a pretty quick failure of the test suite. As such, I personally believe the best approach on Intel/AMD machines would be to: 1) Assume people run 64-bit. 2) Export SAGE64 3) Build a 64-bit version of OpenSSL (the default) 4) Change the broken spkg-install files to remove the restriction in many, that -m64 is added only the operating system is OS X. >>> Note that the current assumption that Sage is building in 32-bit mode >>> unless 'SAGE64' is set is not universally true: >> I'm not making that assumption. > > Sorry. I wasn't implying that _you_ were, only that parts of Sage do. > As an example, readline-6.0.p1/spkg-install contains: > > if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then > echo "Building a 64-bit version of Readline" > ... > else > echo "Building a 32-bit version of Readline" > fi I might have written that bit of code, though I thought it had been removed. I was under the impression at one point that not setting SAGE64 to yes would result in a 32-bit build, but I now know that is not true. >> if [ "x$SAGE64" = "xyes" ] ; then >> if [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xGCC" ] ; then > ... >> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xSun_Studio" ] ; then > ... >> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xIBM_on_AIX" ] ; then > ... > > You might like to look for 'case ... esac' in your sh(1) documentation. Cheers, though I might be inclined to leave that, as I've almost finished what I intended doing on sage-env. I think I need to buy a book on shell scripting. Mine is better than a lot of the things in Sage, but clearly I know a lot less you. >> That way, we have as a variable (CFLAG64) in isolation, as well as in >> CFLAGS. I >> think ECL needs needed -m64 at one point during the link process, so not as >> a >> CFLAG. > > '-m64' or similar will also need to be passed to the link step - LDFLAGS > is normally used for this. > >> # -xcode=pic32 is valid on 64-bit too, despite the name. > > The '32' actually refers to the size of the relocation field. There's > also pic13 on SPARC - which is significantly faster than pic32 when it > can be used. gcc also has '-fPIC' and '-fpic' for different relocation > sizes. >> Any thoughts on that? > > I'm all for centralising as much as possible. My only concern is that > things like PIC choices should ideally be a combination of the compiler > (-fPIC/-fpic or -xcode=pic32/-xcode=pic13) and library (-fpic or > -xcode=pic13 if possible). I do not understand the difference. But I believe most, if not all of the code generated by libtool is using -KPIC if one uses the Sun compiler. -KPIC is equivalent to -xcode=pic32. Where would you decide whether to use xcode=pic32 or xcode=pic13? Would that mean evaluating every package on an individual basis? I do not what to limit performance unnecessarily, or make it hard for anyone to do so in the future, but I feel the simpler this can be kept, the better here. The current situation with tons of hard-coded -fPIC, -soname, -shared etc is not ideal. > I swapped the test for $CC and the usage report because I felt it was > more reasonable to provide a usage message if $CC wasn't set than > complain that $CC is unset. OK, will do so too in testcxx.sh Dave -- 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
