NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/vms/22229

Text File | 1993-01-28 | 4.4 KB | 92 lines

Newsgroups: comp.os.vms
Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!dbased.nuo.dec.com!quark.enet.dec.com!lionel
From: [e-mail] (Steve Lionel)
Subject: Re: fortran/nohpo?
Message-ID: <[e-mail]>
Lines: 79
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
References:  <[e-mail]>
Date: Wed, 27 Jan 1993 16:20:38 GMT


In article <[e-mail]>,
[e-mail] writes:
|>
|>First, after Mark's query, Steve Lionel wrote something about people
|>peeking into the FORTRAN CLDs.  The /[NO]HPO qualifier is documented
|>in *our* HELP text, but maybe that's only because we field tested
|>FORTRAN-HPO.  Can anyone out there confirm/refute this?

I made the comment about "peeking into CLDs" because of the way the question
was phrased.  Mark asked about the "NOHPO" qualifier.  It would only appear
that such a thing existed to someone who looked at the VAX FORTRAN V5.9
CLD file, which is placed in SYS$LIBRARY:.  (FORTRAN-HPO and V6 don't leave
the CLD on the system).  If you had FORTRAN-HPO, you'd know it as the HPO
qualifier and wouldn't be prone to asking what it did.  Certainly the HPO
qualifier was documented for FORTRAN-HPO customers.

|>
|>Second, Bob Marshall ([e-mail]) wrote:
|>
|>>... In many cases they are compiling on a uniprocessor system in our
|>>system which has no vector processor, anyway.
|>>
|>>So, there's at least one situation where the /NOHPO switch makes sense,
|>>even when the FORTRAN-HPO compiler is available.
|>
|>I think that this is wrong, but Steve might correct me.  There are
|>*other* benefits which can be gained by using the HPO compiler.  As I
|>understand things, it does a much better job of code optimization.
|>Also, at least here, vector code is NOT generated unless you explicitly
|>ASK for it via the /VECTOR qualifier.

Right on both counts.  In particular, code that uses COMPLEX data types are
much better optimized by FORTRAN-HPO than by VAX FORTRAN.  Also, FORTRAN-HPO
generates inline code for BLAS routines, which is important to some.  Vector
and multiprocessor code requires use of non-default compiler options.

|>
|>HOWEVER, a co-worker refuses to use the HPO compiler because, in the
|>early field test, we ran into a couple of bugs is the code generator.
|>(These have been fixed, btw.)  The worst problem he had, however, was
|>the COMMON block alignment issue.  He didn't want to change all of the
|>MACRO code, nor did he want to change the build procedures.
|>

Was this the warnings for misaligned fields?  If so, that's easily suppressed
by /WARNINGS=NOALIGNMENT.  However, for V6, NOALIGNMENT is the default.
As for code generator bugs, I know of no cases where the V6 compiler generates
improper code; we've had a six-month field test at sites which use the compiler
in production and which compile millions of lines of code.  We also have our
9000+ program test system which we run frequently.  I fully expect V6.0 to
look to VAX FORTRAN V5.x customers as equally reliable, with a lot more
useful features (and with no increase in price.)  V6 should be on the
March ConDist CD and be shipping to service customers by the end of
February.

|>As for the alignment, depending upon your processor access to non-aligned
|>data may be significantly slower than access to aligned data.

Sort of true.  It is slower, but whether or not it's "significant" is
subjective.  If your program has tens of thousands of unaligned accesses,
aligning the data could result in a noticeable performance boost.  But the
warnings are more important to those using vectors and those porting to
Alpha AXP systems, where natural data alignment is required.  (AXP systems
include alignment "fixup" code, but it's MUCH slower than getting the
alignment right.)

Alignment is really only an issue in COMMONs and RECORDs (or where
EQUIVALENCE is used).  Otherwise, the compiler naturally aligns data (and the
way we do that for stack-allocated double-precision variables is intriguing;
details are in the release notes.) It also tries to longword-align loop tops
for better execution performance.
--

Steve Lionel                    [e-mail]
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062