On Jun 9, 9:09 am, mabshoff <[EMAIL PROTECTED]> wrote: > On Jun 8, 10:59 pm, "Dr. David Kirkby" <[EMAIL PROTECTED]> > wrote: > > Hi Dave, > > > Is there a general policy on whether compiler flags should give the > > best performance on a particular machine, or should the binaries work > > on any similar system? I can see advantages in each. > > Right now we pick up SSE2 automatically in a couple packages, for > example M4RI and ATLAS. Other than that setting CFLAGS & friends is > generally not a good idea unless you are an expert user and as is we > do overwrite those flags in many cases.
I guess my questions was aimed more at SPARC. Do you want to build with something like -xarch=native which would use any instructions available. That seems to be what you are implying you do when you pick up the SEE2 automaticaly. If you chose to use SEE2 instructions on one platform, it would tend to be logical to user UltraSPARC III specific instructions on my Blade 2000. This is quite a different issue from compiler optimisation. As you say, that can break code. > It has certainly been requested and I plan to offer a special > l_KNOW_WHAT_I_AM_DOING_SO_LET_ME_SET_CFLAGS_AND_I_WANT_COMPLAIN_IF_I_BREAK_MY_SAGEBUILD It really needs that for specific packages. ie. R_CFLAGS ICONV_CFLAGS etc since it is clear no single set of CFLAGS are going to be appropiate on every package. > mode, but certain packages like gmp react very badly to even seemingly > innocent CFALGS (think -fast on Solaris), so I will explicitly make it > very, very clear to the user that this is not recommended Even simple > things like "-O3" breaks code and I have had to dial down the > optimizations settings on more than one spkg to avoid breakage. -fast is too powerful for most things. > Most current compilers on x86 default to i585 and on x86-64 it is also > a non-issue. Gains can be found in certain areas, but correctness and > stability are a higher priority than wringing an extra 10% of > performance out of the code . I don't think choosing the architecture optimally can break code - well at least it should not. That's quite different to compiler optimisation. The former just sets what instructions the compiler is allowed to generate. > > I was looking at compiling R on Solaris (and I have now succeeded with > > both gcc and Sun Forte), but the compiler flags one uses depends on > > the above decision. > > Sure. But we will have for hard coded, but customizable flags for Sun > Forte on Solaris at least. I think setting -xarch=native might be a good idea, as it would gain performance at no risk *except* if one built on one platform and tried to use on an older one. Anyway, R seems to be quite critical on compiler flags. The current Sage is building R with cc, even though the rest of it is built with gcc. That seems a bit odd to me. If R does not link with anything else, and is standalone, then compiling that with Sun Forte, even if everything else is done with gcc, would not seem so silly. From what I can see, on Solaris x86, gcc is not capable of building R at all without test failures. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
