Re: GSL on Solaris

["Dr. David Kirkby" <drkirkby at ntlworld dot com>]

"Dr. David Kirkby" wrote:
> 
> Nevin Weinberg wrote:
> >
> > Hi,
> >
> >  I would like to install GSL on a Solaris 9. Is it compatible and
> > if so is there anything special I need to do?
> >
> > Thanks,
> > Nevin Weinberg
> 
> Yes and No. Yes it works (fine on my Sun Ultra 80 running Solaris 9)
> and no there was nothing special I needed to do.

Perhaps this deserved a more complete answer. 

I built gsl-1.3 with gcc-3.2 - no problems at all. I have linked code
compiled with both gcc and Sun's C compiler cc with no problems.

I should I guess rebuild gsl with Sun's compiler, as that generates
much better code on SPARC than what gcc does. If you have cc, I would
be tempted to use that, although I've not tried it. 

If you do use Sun's compiler, be very careful with testing the results
while playing with any optimisation flags. Some of the compiler flags
make assumptions about the code that might not be true. Just adding
every optimisation around will almost certainly get junk produced. 

I got some strange (well basically junk) results using the -fast macro
to cc on some code (nothing to do with gsl). I have copied below a
parts of an email sent to me by someone on what the -fast macro is,
and a bit about compiler optimisations in general. It makes
interesting reading - not just for those using Sun's cc. 



-----Start of quoted email----


...
> > -fast is a macro option that includes some "assertive" flags.
> > Especially, -fsimple=2 allows the compiler to treat
> > floating operations as if they are equivalent mathematical operations.
> 
> What does that actually mean? 

The man pages cc(1) and CC(1) contain very brief explanation about
-fsimple.
For more elaborate description and an dramatic example, 
I'll quote from the book titled
"Techniques for Optimizing Applications: High Performance Computing"
written by Rajat Garg and Ilya Sharapov.

    In most cases, changing the order of the operands or performing
other
    algebraic transformations may result in different round off with
at
    most, the few last digits of the result affected. However, in some
    cases, when the computation is performed with the operands of very
    different magnitude, the cancellation may cause catastrophic
precision
    loss and the result can be changed dramatically. For example, an
    expression -1 + 10^20 - 10^20 + 1 cannot be represented without
    precision loss even in double-precision. Because of the
cancellation,
    it will be computed as 1 if the operations are performed from left
to
    right as is done in Fortran. If the optimizer changes this
expression
    to an algebraically equivalent one 1+10^20-10^20-1, the result of
the
    computation will be -1. Another transformation, 10^20 - 10^20 + 1
- 1,
    leads to the answer 0.

    If the algebraically equivalent transformations allowed by
-fsimple
    considerably change the result of a computation, it may indicate
that
    the algorithm used in the program is numerically unstable. In that
    case, the IEEE compliant computation does not necessarily lead to
the
    correct solution, but rather provides a standardized way of
selecting
    an answer from the range of the possible values.

    c example_order.f
    c f77 example_order.f -o example_order
        real*8 a,b,c,d
        a=-1.0d0
        b=1.0d20
        c=-1.0d20
        d=1.0d0
    c
        print*,"a+b+c+d = ", a+b+c+d
        print*,"d+b+c+a = ", d+b+c+a
        print*,"b+c+a+d = ", b+c+a+d
        end

    example% f77 example_order.f -o example_order
    example% example_order
    a+b+c+d = 1.0000000000000
    d+b+c+a = -1.0000000000000
    b+c+a+d = 0.
-- 
Dr. David Kirkby,
Senior Research Fellow,
Department of Medical Physics,
University College London,
11-20 Capper St, London, WC1E 6JA.
Tel: 020 7679 6408 Fax: 020 7679 6269
Internal telephone: ext 46408
e-mail davek@medphys.ucl.ac.uk