btb@ncoast.UUCP (Brad Banko) (11/20/86)
Hello, Does anybody know of a good ratfor preprocessor... one that doesn't have some of the problems that our 3 have.... one that knows about f77? As an example, the ratfor for loop: for (i=1; i<=n; i = i + 1) translates into the horrible: i = 1 if (.not. (i .le. n)) goto (end of loop) ... i = i + 1 (goto if) (end of loop) rather than into the much more efficient: i = 1 if (i .gt. n) goto (end of loop) ... i = i + 1 (etc.) (end of loop) this may not seem like much, but I have benchmarked the above optimization change against the original code from a ratfor version of sieve, and it makes a factor of 2 difference... who knows how much more could be improved? (Incidentally, the ratfor fortran sieve ran 5 times slower than either the f77, or C sieve, so in other words, a ratfor preprocessor that knows about f77 could translate ratfor whiles and fors into f77 do whiles and dos... resulting in much quicker code.) We have a huge programming system all written in rat4... (Gipsy image processing software), running on a lil' 11/750... If you know of a "modern" rat4 we could get our hands on, I would appreciate it... I would also appreciate it if someone could tell me if the above code is necessary in some way that I am not thinking of? Also, if you, or someone you know has any experience with the Gipsy (General Image Processing System) software originally developed at Virginia Polytechnic Institute, please send me email... this package was originally developed to run on IBM systems, but has been ported (sort of) to VMS... We need help! Thanks, -- Brad Banko ...!decvax!cwruecmp!ncoast!btb Cleveland, Ohio
ken@rochester.ARPA (SKY) (11/21/86)
I guess you didn't get my mail, Brad. Changing the code generation for F77 is easy for both the yacc/C and portable Ratfor version. I can mail you the Ratfor version if you like. If you have only binaries, well that is another story. Ken
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/22/86)
In article <1724@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: > if (.not. (i .le. n)) goto (end of loop) >rather than into the much more efficient: > if (i .gt. n) goto (end of loop) Ratfor was deliberately designed to be as simple as possible, with the understanding that the Fortran compiler would perform optimizations. If your Fortran compiler cannot perform the above optimization, then it must be pretty puny. Beefing up the compiler would be much better than complicating Ratfor.
zben@umd5 (Ben Cranston) (11/24/86)
In article <1724@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: > As an example, the ratfor for loop: > for (i=1; i<=n; i = i + 1) >translates into the horrible: > i = 1 > if (.not. (i .le. n)) goto (end of loop) > ... > i = i + 1 (goto if) > (end of loop) > rather than into the much more efficient: > i = 1 > if (i .gt. n) goto (end of loop) > ... > i = i + 1 (etc.) > (end of loop) Gosh, any Fortran compiler that doesn't produce the same or similar code for these two cases sure seems suspect - are you sure there isn't an "optimize" switch that you could invoke? -- umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS"
levy@ttrdc.UUCP (Daniel R. Levy) (11/27/86)
In article <5401@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: >In article <1724@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: >> if (.not. (i .le. n)) goto (end of loop) >>rather than into the much more efficient: >> if (i .gt. n) goto (end of loop) >If your Fortran compiler cannot perform the >above optimization, then it must be pretty puny. Beefing up >the compiler would be much better than complicating Ratfor. Wonder what compiler was used? Even the "slow, inefficient" UNIX f77 performs that particular optimization by default (no -O). -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
btb@ncoast.UUCP (Brad Banko) (12/01/86)
I appreciate any and all comments about my Ratfor problems. ( if (.not. (a.le.n) ) ..., should go to: if ( a.gt.n ) ... ), I don't know much about compilers. Our Fortran compiler is Vax Fortran, and what I do know is that first, the "optimization" is always "on" unless you turn if off (according to the online help), and second, if the ratfor ( if (.not. (a.le.n))...) is hand optimized to ( if (a.gt.n) ...) the resulting executable file runs twice as fast. The problem seems to be that the compiler is not smart enough to optimize boolean expressions in general... which I don't fault it for, but I don't appreciate the umpteen messages that tell me that my fortran compiler should do the work, because it obviously does not. -- Brad Banko ...!decvax!cwruecmp!ncoast!btb Cleveland, Ohio
joe@dayton.UUCP (Joseph P. Larson) (12/02/86)
In article <1768@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: >... > ( if (.not. (a.le.n) ) ..., should go to: > if ( a.gt.n ) ... ), > > I don't know much about compilers. Our Fortran compiler is >Vax Fortran ... >second, if the ratfor ( if (.not. (a.le.n))...) is hand optimized to >( if (a.gt.n) ...) the resulting executable file runs twice as fast. Hmm. I've looked at the code VAX/VMS FORTRAN produces in the past. The optimization always struck me as being very good. Is this the FORTRAN you are using, or do you use UNIX/Eunice? Also, I assume that either you are doing more hand-optimizations than just this one line, or this is almost your entire routine in order for there to be a difference-factor of 2 for this trivial change. Could you be so nice as to send us (or at least me) the Macro-11 the code produces? I'm curious. (In VAX/VMS FORTRAN, I think you want the /MACH option. Don't do a /FULL list or anything like that). Of course, it could be possible you've stumbled across just the right combination of boolean operators to negate the compiler's ability to optimize, at which point DEC would probably love to receive a fairly detailed description.... -- UUCP: ihnp4!rosevax!dayton!joe Joe Larson ATT : (612) 375-3537 Dayton Hudson Department Store Company (standard disclaimer...) 700 on the Mall Mpls, Mn. 55408