Re: Sun compiler

[Gerhard Niklasch <nikl@mathematik.tu-muenchen.de>]

In response to:
> Message-Id: <200102131731.SAA13888@erato.univ-lille1.fr>
> From: Olivier.Ramare@agat.univ-lille1.fr (Olivier Ramare)
> Date: Tue, 13 Feb 2001 18:31:31 +0100 (MET)
> To: pari-dev@list.cr.yp.to
> 
> Dear developpers,
> 
>   My department bought a Sun compiler that is meant

Which precise version?  (cc -V says...?)

> to make miracles ... if you know how to ask for them !
> That for 64 bits and not 32. Can pari be compiled
> with it ? and if yes, can you send me the proper
> makefile ?

(a) Yes, (b) not necessary.

The following apply whether you compile for 32bit or 64bit:

* Make sure the code generator and cc patches for the relevant
  compiler version are up to date.  (I can tell you the patch
  numbers if you tell me the compiler version.)
* Make sure your PATH is set correctly to have the appropriate
  SUNWspro/bin directory in it, and have it ahead of /usr/ucb
  where an Evil Old Shell Script by the name of "cc" is just
  waiting to jump out and bite you when you least expect it.
* Run fpversion on the machine you intend to run gp on, to get
  an idea of good optimizing options.
* When ./Configure -a asks for the compiler, give it the cc path
  (I always use the full path),  and for the options, use
  -fast -fsimple=1
  followed by what fpversion has told you.  (That must come after
  the -fast macro, because -fast expands to a number of things you
  had better override.)
* Enjoy.

(I haven't tried cc 5.3 yet, but up to 5.2 and using the sparcv8
assembler kernel, I have found gcc-created gp to be noticeably
faster than Sun cc-created gp on identical hardware.  I've been
wondering whether the assembler routines are inhibiting cc's
optimizer... in which case setting arch to "none" might help
somewhat.)

The following applies to 64bit only:

* Right at the start of ./Configure -a, select "none" for the
  architecture, since there are no sparcv9 assembler files yet.
* Add -xarch=v9 to the cc options.  (After -fast and after the
  fpversion-suggested stuff.)  You *must* compile on a sun4u
  system to do this, and the resulting code won't run on anything
  less than v9.  In particular, it won't run on a 32-bit kernel.

Bear in mind that besides changing the default size of long
to 64bit, this mode has a number of other effects.  Pointers
occupy twice as much space, leading to general binary bloat
and increased runtime memory hunger.  This in turn reduces
cache efficiency, and may result in significant performance
losses.  v9 is meant for applications which need the huge
(2^48, more or less)  address space supported by the 64bit
kernel, not for apps which merely want to have 64bit longs
(which could be done in the v8 model, but would require
considerable source code modifications, aside from blowing
away the basic assumption that a pointer can be cast to a
long and vice versa without losing any bits).

Igor Schein has been exploring this area for longer than I have,
and may be able to help.  I owe the fpversion hint to him.  (Gee,
even I don't know everything there is to know about the Sun com-
pilers, although I earn much of my living with them. :)

Hope this helps,
Gerhard