[Python-Dev] HP-UX clean-up

[Nick Monyatovsky]

>------------------- Message from Skip Montanaro --------------------
>
>      Martin> 2. Assuming -Wl,+s -Wl,+k are warnings: ...
>
>  They cause the +s and +k options to be passed to the linker.  They could
>  also be written as -Wl,+s,+k.
>
>      Martin> 4. On the model selection options, I don't quite understand
>      Martin>     why you say that this set of options gives portable
binaries.
>      Martin>     I would have thought that +DA1.1 +DS2.0 is the set of option
>      Martin>     that gives portable binaries.
>
>  I found an HP-UX machine I could log into which has aCC installed.  It's
>  just a 10.20 machine.  HP's are on the way out here.  I didn't found any
>  running HP-UX 11.
>
>  About +DA and +DS the aCC man page has this to say:
>
>             +DAarchitecture
>                            Generate code for a particular version of the PA-
>                            RISC architecture specified.  Also specifies which
>                            version of the HP-UX math library to link when you
>                            have specified -lm.
>
>                            Note Object code generated for PA-RISC 2.0 will
>                            not execute on PA-RISC 1.1 systems.
>
>                            To generate code compatible across PA-RISC 1.1 and
>                            2.0 workstations and servers, use the +DAportable
>                            option.  For best performance use +DA with the
>                            model number or architecture where you plan to
>                            execute the program.  See the file
>                            /opt/langtools/lib/sched.models for a list of
>                            model numbers and their PA-RISC architecture
>                            designations.
>
>                            If you do not specify this option, the default
>                            object code generated is determined automatically
>                            as that of the machine on which you compile.
>
>                            Examples
>                                           +DA1.1
>                                           +DA867
>                                           +DA2.0
>                                           +DAportable
>
>                            The first two examples generate code for the PA-
>                            RISC 1.1 architecture. The third example generates
>                            code for the PA-RISC 2.0 architecture. The fourth
>                            example generates code compatible across PA-RISC
>                            1.1 and 2.0 workstations and servers.
>
>             +DSmodel       Use the instruction scheduler tuned to the model
>                            specified.  If this option is not used, the
>                            compiler uses the instruction scheduler for the
>                            architecture on which the program is compiled.
>                            The architecture is determined by uname() (see
>                            uname(2)).  model can be a model number, PA-RISC
>                            architecture designation or PA-RISC processor
>                            name.  See the file
>                            /opt/langtools/lib/sched.models for a list of
>                            model numbers and processor names.
>
>  Obviously, due to the age of the OS on this machine, there's no mention of
>  Itanium.
>
>      >> Maybe there should also be some sort of option for expects who will
>      >> not want Python to be compiled for generic processor; who might
>      >> purposefully want to compile Python on their particular hardware and
>      >> have it fully optimized for it to gain maximum performance.
>
>      Martin> No, no, no. If you want to highly tune your build, you are
>      Martin> expected to edit the makefile. Providing an explicit option for
>      Martin> that will place a burden on users who are not able to answer
>      Martin> difficult build questions (and, trust me, this is the majority
>      Martin> of the users).
>
>  It would also make the configure script that much more fragile.
>
>  Skip
>
>
>  _______________________________________________
>  Python-Dev mailing list
>  Python-Dev at python.org
>  http://mail.python.org/mailman/listinfo/python-dev
>  Unsubscribe:
http://mail.python.org/mailman/options/python-dev/mon%40abaqus.com
>--------------------------------------------------------

As far as architectures are concerned, we can no longer find any PA 1.1
machines. All machines that we deal with happen to be PA 2.0 machines.  So far
we have had no trouble with binaries compiled for PA 2.0. (We re-distribute
Python to users in binary form). We had initially also tried to compile for 1.1
and Portable, but found we that those binaries run much slower: there was about
20% performance improvement for switching from PA 1.1 to PA 2.0. But switching
from PA-RISC 32-bit to 64-bit brought no performance improvements at all.

Binaries compiled for PA 2.0 in 32-bit run successfully on all current
processors: 32-bit RISC, 64-bit RISC, as well as Itanium machines.
So PA-RISC 2.0 32-bit seems like a reasonable default. Could other users please
weigh in here if this is not your typical setup?

---
I also accept the point that configure should have a reasonable default when
used with no arguments. And what that particular default is, is not
particularly relevant. What's important is that it should pick one of the
broad/generic setups we are discussing right now, and not tie itself to a very
particular hardware on a single machine.

What's also good about this, is that at least it will display which
Architecture it has chosen (if you look at the -DA -DS options it picked), and
not just compile something silently that might be very unportable.


Thank you,  -- Nick Monyatovsky -- mon at abaqus.com