On Jun 9, 1:45 am, "Dr. David Kirkby" <[EMAIL PROTECTED]> wrote:
> 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.
Yes, but that is usually due to some autodetection in the code. We can
definitely discuss some sensible default compiler settings for the Sun
compiler.
> 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.
Well, setting arch to core2 does break Sage so badly it doesn't even
start any more, so I am skeptical here. If you give people enough rope
they *will* hang themselves and I have seen a lot of build bug reports
in the past on sage-devel and in IRC where I just wandered how people
could come to the conclusion that setting $FOOBAR is a good idea. So I
am all for an expert option, but the documentation to that will be
well hidden in the manual to avoid too many bug reports from
inexperienced people.
> > 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
Well, that would add somewhere in the neighborhood of 50 x number of
flags and I am not sure that is a practical solution. It is certainly
doable, but having one global set of flags that can be individually
overwritten like you suggested above seems more desirable, i.e. for R
if
SAGE_FCLAGS
is non empty use that unless R_CFLAGS is set. If both of them are
empty just go with the default. But if we implement that it spkg-
install should clearly log to the build log that some flags are being
overwritten and be very specific about it. As is I can only imagine
this to be a support nightmare without logging and with logging I
foresee a lot of emails I have to write to people that explains that
using too many CFLAGS will break their build. For custom FLAGS I
*will* mandate the test suite of the spkg being build with custom
flags being run so that in case of failure it will be caught early.
I also reserve the right to call anybody who went overboard with flags
and broke the build a "ricer" :)
> 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.
I know, but people generally do not understand optimization flags. I
have seen it happen plenty of times :)
> > 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.
As mentioned above I know cases where setting $ARCH does break the
code badly. It should not in a perfect world, but it does.
> > > 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.
Yep.
> 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.
Well, that is an oversight on our end since on every supported
platform cc==gcc. We have a couple tickets open that are supposed to
clear that up and also honor CC, CXX and so on which we also do not
do. I have a long list of spkg-install cleanup tasks and I will add
custom flags to the list.
> 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.
As is I tested R 2.6.1 on OSX, Linux and Solaris and the test suite
failed on every platform I tested. You can draw your own conclusion
what I called R afterwards. There is already a ticket for that and I
hope that the 2.7 upgrade will fix the test suite.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
