home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 22139 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  1.8 KB
  1. Path: sparky!uunet!stanford.edu!agate!ucbvax!U.WASHINGTON.EDU!DEREK
  2. From: DEREK@U.WASHINGTON.EDU
  3. Newsgroups: comp.os.vms
  4. Subject: Re: fortran/nohpo?
  5. Message-ID: <8CF0CF8DB01F23A12E@MAX.U.WASHINGTON.EDU>
  6. Date: 26 Jan 93 22:32:00 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 39
  11.  
  12. Two comments come to mind here.
  13.  
  14. First, after Mark's query, Steve Lionel wrote something about people
  15. peeking into the FORTRAN CLDs.  The /[NO]HPO qualifier is documented
  16. in *our* HELP text, but maybe that's only because we field tested
  17. FORTRAN-HPO.  Can anyone out there confirm/refute this?
  18.  
  19. Second, Bob Marshall (marshall@force.ssd.lmsc.lockheed.com) wrote:
  20.  
  21. >... In many cases they are compiling on a uniprocessor system in our
  22. >system which has no vector processor, anyway.
  23. > 
  24. >So, there's at least one situation where the /NOHPO switch makes sense,
  25. >even when the FORTRAN-HPO compiler is available.
  26.  
  27. I think that this is wrong, but Steve might correct me.  There are
  28. *other* benefits which can be gained by using the HPO compiler.  As I
  29. understand things, it does a much better job of code optimization.
  30. Also, at least here, vector code is NOT generated unless you explicitly
  31. ASK for it via the /VECTOR qualifier.
  32.  
  33. HOWEVER, a co-worker refuses to use the HPO compiler because, in the
  34. early field test, we ran into a couple of bugs is the code generator.
  35. (These have been fixed, btw.)  The worst problem he had, however, was
  36. the COMMON block alignment issue.  He didn't want to change all of the
  37. MACRO code, nor did he want to change the build procedures.
  38.  
  39. As for the alignment, depending upon your processor access to non-aligned
  40. data may be significantly slower than access to aligned data.
  41.  
  42. -Derek S. Haining
  43.  University Computing Services
  44.  University of Washington
  45.  Seattle, Washington  98195 
  46.  (206) 543-5579
  47.  
  48.  DEREK@MAX.BITNET
  49.  DEREK@MAX.U.WASHINGTON.EDU
  50.  
  51.