philw@pharma.UUCP (Philip Michael Williams) (02/28/91)
Greetings,
I was very interested in a news article about a PD FORTRAN-to-C converter,
F2C. As I can't afford #500 for a 030 Fortran compiler I amy very keen to
get hold of a copy of this F2C. I haven't seen it around anywhere and was
wondering where I can get it from. Any help, someone, please !
For those lucky ones who run AC/Fortran, does equivalent software run quicker
in FORTRAN on the Amiga than it does in C. I have done some extensive tests
on Unix workstations (Apollo, Silicon Graphics, Hewlett Packard and E&S) and
find that FORTRAN code runs faster than the same code ported to C. This may
not hold for C code ported to FORTRAN, but that's another story. A 2000 with
a 25MHz 68030 (A2630) runs small code faster than an 8MB 33MHz Apollo DN4500
Unix workstation (again 68030 based). BUT, the same code running in FORTRAN
runs twice as fast on the 4500. Perhaps we should stop this shift to 'C',
the trendy language, for all our programming and us FORTRAN for the tasking
stuff.
Are there other Amiga FORTRAN compilers other than Absofts ?
Any help with F2C greatly appreciated.
--
Phil Williams cbmuk!cbmuka!pharma!philw
Dept Pharmaceutical Sciences
Univeristy of Nottingham JANET: paxpw@uk.ac.nott.vax
Nottingham NG7 2RD
UK ben@epmooch.UUCP (Rev. Ben A. Mesander) (03/01/91)
>In article <philw.0043@pharma.UUCP> philw@pharma.UUCP (Philip Michael Williams) writes: [...] > Perhaps we should stop this shift to 'C', >the trendy language, for all our programming and us FORTRAN for the tasking >stuff. Do you mean that compiled fortran is faster than fortran converted to C, and then compiled? This doesn't surprise me at all. As for whether compiled FORTRAN is faster/slower than compiled C, this is generally dependent on the architecture of the machine, and how good the authors of the compiler were. I can *write* most C programs faster than equivalent FORTRAN programs, although I've spent a lot more time coding in FORTRAN than C. >Are there other Amiga FORTRAN compilers other than Absofts ? On ab20.larc.nasa.gov, there is a PD F77 compiler called BCF77. I ftp'd it, and tried to compile a program posted on alt.folklore.computers that was a extrememly contorted and complex fortran program. It compiled it and executed it correctly, which surprised me. There is little English documentation, but F77 is F77 the world round... > Phil Williams cbmuk!cbmuka!pharma!philw -- ben@epmooch.UUCP ben%servalan.UUCP@uokmax.ecn.uoknor.edu {chinet,uokmax}!servalan!epmooch!ben (Ben Mesander) War in gulf: newpath 288 396 216 0 360 arc 288 612 moveto 288 180 lineto 288 396 moveto 136 244 lineto 288 396 moveto 440 244 lineto 36 setlinewidth stroke showpage
ben@epmooch.UUCP (Rev. Ben A. Mesander) (03/01/91)
>In article <2412@ria.ccs.uwo.ca> ptoper@obelix (Andy Nagy) writes: [...] > 2) Does anyone know why a Fortran compiler might produce faster execut- > ables than C (asside from the obvious 'because its better at that > job'). Is it because of the design of the language or the compiler > or ... Bingo! The design of the language makes it quite easy to compile. It doesn't place as many demands on the machine as C does. For example, FORTRAN subprogram arguments are passed by reference, rather than by value. While it makes it somewhat annoying to code recursive routines in FORTRAN, I beleive that this is faster on most machine architectures: Push address of arg on stack call subprogram versus Fetch contents of variable push on stack call subprogram There are others. This is just off the top of my head. >Andy Nagy (ptoper@asterix.gaul.csd.uwo.ca) -- ben@epmooch.UUCP ben%servalan.UUCP@uokmax.ecn.uoknor.edu {chinet,uokmax}!servalan!epmooch!ben (Ben Mesander)
ptoper@obelix (Andy Nagy) (03/02/91)
In article <philw.0043@pharma.UUCP>, philw@pharma.UUCP (Philip Michael Williams) writes: [stuff deleted] > For those lucky ones who run AC/Fortran, does equivalent software run quicker > in FORTRAN on the Amiga than it does in C. I have done some extensive tests > on Unix workstations (Apollo, Silicon Graphics, Hewlett Packard and E&S) and > find that FORTRAN code runs faster than the same code ported to C. This may > not hold for C code ported to FORTRAN, but that's another story. A 2000 with > a 25MHz 68030 (A2630) runs small code faster than an 8MB 33MHz Apollo DN4500 > Unix workstation (again 68030 based). BUT, the same code running in FORTRAN > runs twice as fast on the 4500. Perhaps we should stop this shift to 'C', > the trendy language, for all our programming and us FORTRAN for the tasking > stuff. [other stuff deleted] > Phil Williams cbmuk!cbmuka!pharma!philw > Dept Pharmaceutical Sciences > Univeristy of Nottingham JANET: paxpw@uk.ac.nott.vax > Nottingham NG7 2RD > UK Two questions: 1) What specific aplications are you running (I would assume real/float intensive stuff) 2) Does anyone know why a Fortran compiler might produce faster execut- ables than C (asside from the obvious 'because its better at that job'). Is it because of the design of the language or the compiler or ... ------------------------------------------------------------------------------- Andy Nagy (ptoper@asterix.gaul.csd.uwo.ca) The University of Western Ontario, London, Canada "Dee do do do, dee da da da, thats all I want to say to you" -- The Police
ben@epmooch.UUCP (Rev. Ben A. Mesander) (03/04/91)
>In article <1991Mar4.191533.3300@jato.jpl.nasa.gov> jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes: >>me: [..] >>For example, FORTRAN >>subprogram arguments are passed by reference, rather than by value. > > ...And pointers to objects in 'C'. How are they passed? This is true. But how many C programs do you see that pass only pointers to objects around? FORTRAN tends to be a bit faster also when you are dealing with things like the COMPLEX datatype. Oh, and yes, you can define C macros to handle similar things. Your assertation that it is entirely coding style *is* incorrect, however. It depends on the machine architecture quite a bit. FORTRAN on a Prime Mini, with an assembler instruction set designed for FORTRAN (In large part, the OS is written in FORTRAN), will perform well. C code on that machine is both larger and slower. Pointers to chars and pointers to ints are different lengths, it is impossible to point to 'byte' objects without trickery, and a segmented architecture make it a pretty "C-hostile" environment. None of this has much to do with the Amiga, however. > Jeff -- ben@epmooch.UUCP ben%servalan.UUCP@uokmax.ecn.uoknor.edu {chinet,uokmax}!servalan!epmooch!ben (Ben Mesander)
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (03/05/91)
In article <2412@ria.ccs.uwo.ca> ptoper@obelix (Andy Nagy) writes: >In article <philw.0043@pharma.UUCP>, philw@pharma.UUCP (Philip Michael >Williams) writes: >[stuff deleted] >> For those lucky ones who run AC/Fortran, does equivalent software run quicker >> in FORTRAN on the Amiga than it does in C. I have done some extensive tests >> on Unix workstations (Apollo, Silicon Graphics, Hewlett Packard and E&S) and >> find that FORTRAN code runs faster than the same code ported to C. This may >> not hold for C code ported to FORTRAN, but that's another story. A 2000 with >> a 25MHz 68030 (A2630) runs small code faster than an 8MB 33MHz Apollo DN4500 >> Unix workstation (again 68030 based). My A2000 can compile 'C' source code faster than my SUN 3/160M can. Of course, the SUN has its hands full. The Amiga has a number of background tasks going as well, but nothing like the SUN. USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND root 4673 46.9 5.0 96 360 ? R < 10:05 6:21 jplmrretr -a ... root 4684 30.8 5.9 160 424 p3 R 10:14 0:00 ps -ugax root 4685 15.4 3.5 48 248 p3 S 10:14 0:00 more jdickson 1388 6.0 5.9 288 424 p3 S Mar 1 0:41 shelltool -Wp 0 326 .. root 2 0.0 0.0 0 0 ? D Feb 28 0:00 pagedaemon root 91 0.0 0.0 88 0 ? IW Feb 28 0:00 rpc.lockd jdickson 1377 0.0 0.0 80 0 co IW Mar 1 0:02 -csh (csh) root 1 0.0 0.0 56 0 ? IW Feb 28 0:03 /sbin/init - jaw 4454 0.0 0.0 80 0 p0 IW 08:16 0:02 -csh (csh) root 52 0.0 0.0 80 0 ? IW Feb 28 0:19 portmap root 65 0.0 0.0 24 0 ? I Feb 28 0:00 (biod) root 66 0.0 0.0 24 0 ? I Feb 28 0:00 (biod) root 55 0.0 0.0 56 0 ? IW Feb 28 0:00 keyserv root 77 0.0 0.0 64 0 ? IW Feb 28 0:15 syslogd root 61 0.0 1.6 48 112 ? S Feb 28 1:15 in.routed root 105 0.0 0.0 64 0 ? IW Feb 28 0:07 cron root 64 0.0 0.0 24 0 ? I Feb 28 0:00 (biod) root 0 0.0 0.0 0 0 ? D Feb 28 0:05 swapper root 67 0.0 0.0 24 0 ? I Feb 28 0:00 (biod) root 113 0.0 0.0 72 0 ? IW Feb 28 0:00 /usr/lib/lpd jdickson 1389 0.0 0.0 64 0 p3 IW Mar 1 0:00 -bin/csh (csh) jdickson 1342 0.0 0.0 96 0 ? IW Mar 1 0:06 selection_svc jdickson 1381 0.0 0.0 104 0 co IW Mar 1 0:46 Mail -N -B -f /tmp/MT... dickson 1385 0.0 0.0 64 0 p1 IW Mar 1 0:00 -bin/csh (csh) root 85 0.0 0.0 128 0 ? IW Feb 28 0:07 /usr/lib/sendmail -bd jdickson 1379 0.0 0.0 264 0 co IW Mar 1 0:03 suntools -b 0 0 0 -f jdickson 1387 0.0 0.0 64 0 p2 IW Mar 1 0:00 -bin/csh (csh) jdickson 1384 0.0 0.0 296 0 p1 IW Mar 1 0:05 cmdtool -Wp 542 0 -Ws root 102 0.0 0.0 24 16 ? IW Feb 28 17:31 update jdickson 1386 0.0 0.0 288 0 p2 IW Mar 1 2:00 shelltool -Wp 502 99 jdickson 1380 0.0 13.0 520 928 co S Mar 1 2:15 mailtool -i 5 -Wp 144 jdickson 4491 0.0 0.8 32 56 p2 S 08:55 0:08 telnet 128.149.4.11 jdickson 1388 0.0 6.8 288 488 p3 S Mar 1 0:43 shelltool -Wp 0 326 -Ws root 4453 0.0 0.0 56 0 ? IW 08:16 0:01 in.rlogind root 110 0.0 0.0 56 0 ? IW Feb 28 0:09 inetd jaw 4469 0.0 2.3 56 168 p0 S 08:29 0:00 tail -f jplmrlog root 4680 0.0 2.7 64 192 p3 S 10:13 0:00 -u (csh) I apologize for tying up bandwidth, but I justed wanted to stress the point that you cannot compare apples and oranges. Jeff
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (03/05/91)
In article <ben.5136@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>In article <2412@ria.ccs.uwo.ca> ptoper@obelix (Andy Nagy) writes: >[...] >> 2) Does anyone know why a Fortran compiler might produce faster execut- >> ables than C (asside from the obvious 'because its better at that >> job'). Is it because of the design of the language or the compiler >> or ... > >Bingo! The design of the language makes it quite easy to compile. It doesn't >place as many demands on the machine as C does. "IT" is you. How much of a strain is put on the machine depends on your coding techniques. "How are some programs so damm small" was all about this. For example, FORTRAN >subprogram arguments are passed by reference, rather than by value. ...And pointers to objects in 'C'. How are they passed? >>Andy Nagy (ptoper@asterix.gaul.csd.uwo.ca) >-- >ben@epmooch.UUCP ben%servalan.UUCP@uokmax.ecn.uoknor.edu >{chinet,uokmax}!servalan!epmooch!ben (Ben Mesander) Jeff
judge@alchemy.tcnet.ithaca.ny.us (rory toma) (03/05/91)
Thanks for all thehelp - I went out and purchased Absoft's Fortran 020 version. You guys forgot anotherreason why FORTRAN is faster than C. It takes me twice the time to WRITE an equivalent C program. 8-) rory
m0154@tnc.UUCP (GUY GARNETT) (03/06/91)
[Why a FORTRAN compiler might produce faster code than a C compiler]
I presume that the programs in question are some sort of scientific
software that does some heavy number crunching (the kind of work that
FORTRAN has traditionally done). Now, FORTRAN compilers have been
around a long time (much longer than C) and are used for crunchy
problems where small efficencies count a lot. I would expect that the
complier has very good optimizing routines for the kind of code
FORTRAN is likely to be used for, and given how long FORTRAN has been
around, I would expect that the optimizer algorithm has every trick in
the trade, and then some. Since most of these calculations involve
floating-point math, I would also expect a great deal of time and
effort to be spent optimizing the heck out of the floating-point
library.
C seems to be designed for manipulating data structures, and I would
expect the kinds of optimizations made by a C compiler to be different
than those made by a FORTRAN number cruncher. In addition, I think
that the C floating-point routines are given less priority, and are
therefore not as highly efficient as the FORTRAN ones. On the other
hand, if a classic C program was ported to FORTRAN (assuming that it
could even be done) I would expect it to run much slower in FORTRAN
than in the original.
On the IBM mainframe I use at work, the FORTRAN compiler (IBM VS
FORTRAN) can generally produce smaller and faster code than most
assembly language coders; this is because the comiler has information
on *ALL* the instruction modes and quirks (more than most programmers
can remember), and analyses more different options for the code than
most programmers have time for (it can even re-arrange your program,
moving entire chunks of code, for greater efficency). On this system,
writing fast code means writing your program so that the FORTRAN
compiler can tell what it is you are trying to do, and then letting
the compiler figure out the best way to do it.
Wildstar
Mild-Mannered IBM 3090 Programmer by day ...
... Wild-Eyed Amiga Fanatic by Night