quan@sol.surv.utas.oz (Stephen Quan) (01/23/91)
I am currently on a project for surveyors and recently attempted to port
the code from our Sun workstation to a PC. Unfortunately, the original
code needed double precision arrays of the order of 50000 elements or
higher.
We believe that the current version of Microsoft Fortran falls down
because it could not handle such code so I pushed the department to go
for the Lahey Fortran F77L compiler. However, I now believe that the
F77L compiler will not solve this problem either.
Cause of problem DOUBLE PRECISION BIG(3,50000)
Synopsis of problem compiler won't compile code for BIG is size 3x50000.
Synopsis 2 PC won't load executable when BIG is size 3x4000.
Synopsis 3 Seems to runs ok, when BIG is size 3x3000.
Current Compiler Microsoft Fortran.
Current Size of EXE About 150K (for both Synopsis 2 and 3).
Question 1 Will F77L handle this problem?
Question 2 Does F77L allocated space for arrays in the EXE?
- Will I get a larger EXE file? (somewhat 600K?).
Question 3 Is there a compiler that would solve this problem?
There is little chance that I can push the department to get an F77L/EM,
but I would be interested if that or any other compiler would solve my
problem. If all fails, I probably replaced the array with random
accessing a large file instead.
--
Stephen Quan,
University of Tasmania.news@oasys.dt.navy.mil (USENET News System) (01/23/91)
~ Sorry to post this, but it bounced when I tried to mail it (Host unknown) ~ ~ In article <quan.664590845@sol> quan@sol.surv.utas.oz (Stephen Quan) writes: >I am currently on a project for surveyors and recently attempted to port >the code from our Sun workstation to a PC. Unfortunately, the original >code needed double precision arrays of the order of 50000 elements or >higher. > ~ [Stuff deleted] ~ >Cause of problem DOUBLE PRECISION BIG(3,50000) >Synopsis of problem compiler won't compile code for BIG is size 3x50000. >Synopsis 2 PC won't load executable when BIG is size 3x4000. >Synopsis 3 Seems to runs ok, when BIG is size 3x3000. >Current Compiler Microsoft Fortran. >Current Size of EXE About 150K (for both Synopsis 2 and 3). > >Question 1 Will F77L handle this problem? >Question 2 Does F77L allocated space for arrays in the EXE? > - Will I get a larger EXE file? (somewhat 600K?). >Question 3 Is there a compiler that would solve this problem? > >There is little chance that I can push the department to get an F77L/EM, >but I would be interested if that or any other compiler would solve my >problem. If all fails, I probably replaced the array with random >accessing a large file instead. ~ Hello; I can't directly answer any of your questions, but I might be able to provide some insight to your problem. To have an Double Precision array that is (3,50000) would require: ~ (3 * 50000)elements * 8bytes/element = 1,200,000 bytes = 1,171.875Kbytes ~ This is the amount of memory required to hold that array in memory, since a PC can only access 640 Kbytes, there is not enough memory to hold your array im memory let alone the rest of your program. The only way I can see out of your problem, other than the file approach you mention is to get a 386 machine and a compiler that would create a protected mode program. ~ Sorry I couldn't help you more, but I wanted to share some insight into your problem ~ Joe White jwhite@dtoa3.dt.navy.mil David Taylor Research Center, Annapolis MD ~
3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) (01/24/91)
In article <quan.664590845@sol> quan@sol.surv.utas.oz (Stephen Quan) writes: >[...] >Cause of problem DOUBLE PRECISION BIG(3,50000) >Synopsis of problem compiler won't compile code for BIG is size 3x50000. >Synopsis 2 PC won't load executable when BIG is size 3x4000. >Synopsis 3 Seems to runs ok, when BIG is size 3x3000. >[...] >Question 1 Will F77L handle this problem? >Question 2 Does F77L allocated space for arrays in the EXE? > - Will I get a larger EXE file? (somewhat 600K?). >Question 3 Is there a compiler that would solve this problem? This is a partial answer to Q.2. Try this, or some variant thereof: AUTOMATIC DOUBLE PRECISION BIG(3,5000) (the `automatic' keyword may be wrong.) If it works, BIG will be allocated at startup instead of statically filling the .exe with zeroes. --Pierre Asselin, R&D, Applied Magnetics Corp. I speak for me.
tholen@uhccux.uhcc.Hawaii.Edu (David Tholen) (01/24/91)
In article <quan.664590845@sol>, quan@sol.surv.utas.oz (Stephen Quan) writes: > Cause of problem DOUBLE PRECISION BIG(3,50000) > Current Compiler Microsoft Fortran. > > Question 1 Will F77L handle this problem? > Question 3 Is there a compiler that would solve this problem? [the above was heavily edited] Our machine also bounced mail with "Host unknown", so I'm resorting to a posting. I don't think mail to Australia has ever gone through for me. Anyway... It's my understanding that Lahey's F77L is limited to the available memory in a 640 kbyte maximum DOS world. Given the space consumed by the operating system, you can probably manage at most around 600 kbytes for data, and probably less depending on the size of your code. So, in answer to Question 1, I don't think F77L will handle your problem. Joe White suggested getting a 386 and a protected-mode compiler. While this will work, it's an expensive way to go. If your current compiler is version 5.0 or 4.1, and if your machine is a 286 or better, then switching to OS/2 will do the job for a lot less money. The current Microsoft FORTRAN can create an array almost 16 Mbytes in size on an OS/2 machine, enough to easily swallow your 1.2 Mbyte BIG array. So the answer to Question 3 is yes, and you've already got the compiler for the job (just not the right operating system). And with OS/2 version 2.0 and 32-bit compilers around the corner, these DOS-extender protected-mode compilers will be given a run for their money.
S.J.Lovatt@massey.ac.nz (S.J. Lovatt) (01/24/91)
quan@sol.surv.utas.oz (Stephen Quan) writes: > I am currently on a project for surveyors and recently attempted to port > the code from our Sun workstation to a PC. Unfortunately, the original > code needed double precision arrays of the order of 50000 elements or > higher. > > We believe that the current version of Microsoft Fortran falls down > because it could not handle such code so I pushed the department to go > for the Lahey Fortran F77L compiler. However, I now believe that the > F77L compiler will not solve this problem either. > > Cause of problem DOUBLE PRECISION BIG(3,50000) > > Question 1 Will F77L handle this problem? No - sorry. F77L/EM might, but your problem is more basic than just the compiler. > Question 2 Does F77L allocated space for arrays in the EXE? > - Will I get a larger EXE file? (somewhat 600K?). Yes, F77L allocates space for arrays in the EXE, but that is not your difficulty. Your problem is that the 64kB segment size limitation on an 8088 processor (as found in a PC) restricts the size of just about any static data structure in just about any PC programming language to 64kB or less. > Question 3 Is there a compiler that would solve this problem? > > There is little chance that I can push the department to get an F77L/EM, > but I would be interested if that or any other compiler would solve my > problem. If all fails, I probably replaced the array with random > accessing a large file instead. > -- > Stephen Quan, > University of Tasmania. All the F77 compilers that I've seen advertised which handle this problem are at least as costly as F77L/EM and all require a DOS Extender, and special linker (eg those produced by Phar Lap and others) which are an additional cost. All require at least an AT-compatible and extra memory, as you can get around the segment size limit on a '286 or '386 by running in 'protected mode'. Thus, solving your problem will probably cost you either: (a) lots of money or: (b) lots of time I have found this sort of problem to be a major difficulty porting big Fortran programs to a PC. It is possible, of course, that the program uses only a fraction of the 3*50000 elements. If you can trim the space required down a bit, then you could split the array into three and then the biggest you could have would be about (DOUBLE being 8 bytes): DOUBLE PRECISION BIG1(8000),BIG2(8000),BIG3(8000) Alternatively, given that calculations within the math coprocessor are always done with 10 byte REALs, if you do not actually need to store results as DOUBLE PRECISION, but only calculate at high precision, then you could have arrays such as: REAL BIG1(16000),BIG2(16000),BIG3(16000) ... since REALs are 4 bytes, and rely upon the compiler to (hopefully) do calculations on the 'x87 stack and not use intermediate variables. I wish you the best of luck. - Simon -- Simon Lovatt | S.J.Lovatt@massey.ac.nz | Dept of Biotechnology | | Massey University, N.Z. | |
quan@sol.surv.utas.edu.au (Stephen Quan) (01/24/91)
tholen@uhccux.uhcc.Hawaii.Edu (David Tholen) writes: >In article <quan.664590845@sol>, quan@sol.surv.utas.oz (Stephen Quan) writes: >> Cause of problem DOUBLE PRECISION BIG(3,50000) >> Current Compiler Microsoft Fortran. >> >> Question 1 Will F77L handle this problem? >> Question 3 Is there a compiler that would solve this problem? >[the above was heavily edited] >Our machine also bounced mail with "Host unknown", so I'm resorting to a >posting. I don't think mail to Australia has ever gone through for me. >Anyway... I checked my postings and noticed it had the wrong address, it should have been quan@sol.surv.utas.edu.au instaled of quan@sol.surv.utas.oz, the news server we have down here probably hasn't been updated yet. Sorry guys. (I fixed it this time, temporarily, by forgery!). Thanks to all that helped. The application involved designing a program for middle-budget consumers with GIS software. It turns out that using 386 or 486 as suggested wasn't our first choice, because that would force consumers to get an new PC. So with all things in consider I will code it as randomly accessing a file, and read-only access to BIG is via a function: double precision dtemp(3) character*24 buffer equivalence (dtemp,buffer) c .. Eg modifying an existing array. 1 format(a24) open (10,file='big.dat',access='direct',recl=24,form='formatted') dtemp(1) = 555.555 dtemp(2) = 23.34 dtemp(3) = 432.43 write (10,1,recl=5387) buffer : double precision function big(i,j) double precision dtemp(3) character*24 buffer equivalence (dtemp,buffer) 1 format(a24) read (10,1,rec=j) buffer big = dtemp(i) return end Once BIG.DAT has been generated with our data, we will access it read-only. I am planning to implement a saved common block for a cache-type array to speed up access to BIG. Once again, thanks for all your comments. -- quan@sol.surv.utas.edu.au / quan@131.217.30.1 Stephen Quan, University of Tasmania.
tang@venus.ycc.yale.edu (01/25/91)
>I am currently on a project for surveyors and recently attempted to port >the code from our Sun workstation to a PC. Unfortunately, the original >code needed double precision arrays of the order of 50000 elements or >higher. > >We believe that the current version of Microsoft Fortran falls down >because it could not handle such code so I pushed the department to go >for the Lahey Fortran F77L compiler. However, I now believe that the >F77L compiler will not solve this problem either. > I normally use a MICROVAX II to develop programs, but occasionally I also use a PC for that purpose. The type of work that I do requires several double-precision arrays of sizes on the order of (100 by 100 by 10). But I have to reduce the size to (10 by 10 by 10) on PC because the program code section took up about 400KB. The compilers I use are Microsoft Fortran and Ryan McFarland Fortran (old, v1 ?). Either one meets my needs, but I perfer RM Fortran because, apparently, it comforms more closely to VAX Fortran. However, they have the inherent problem of program (code and data) size restriction (640kb DOS limit). MS Fortran has various memory models which you can choose. These models impose various restrictions on the size of code and/or data. >Cause of problem DOUBLE PRECISION BIG(3,50000) >Synopsis of problem compiler won't compile code for BIG is size 3x50000. > The size of BIG in this case is > 1MB. This program clearly cannot run or compile with MS Fortran (not RM Fortran either). >Synopsis 2 PC won't load executable when BIG is size 3x4000. > The size of BIG is ~94KB. >Synopsis 3 Seems to runs ok, when BIG is size 3x3000. >Current Size of EXE About 150K (for both Synopsis 2 and 3). > The size of BIG is ~71KB. Based on the size of EXE, I have the following suggestions. Do a CHKDSK to find out the available amount of memory. Check the results obtained from this array size (3000). I think you might not have the right answer. Because of DOS, there is a 64KB segment limitation on code and data size. Since the size of BIG is larger than 64KB, there might be a problem here. Try compiling the program with the \AH qualifier which removes the 64KB restriction. The penalty is execution efficiency. >Question 1 Will F77L handle this problem? > Not clear, because of the origin of the problem. Do try to compile the program with the \AH qualifier. (Most conventional compilers are more-or-less the same.) >Question 2 Does F77L allocated space for arrays in the EXE? > - Will I get a larger EXE file? (somewhat 600K?). >Question 3 Is there a compiler that would solve this problem? > >There is little chance that I can push the department to get an F77L/EM, >but I would be interested if that or any other compiler would solve my >problem. If all fails, I probably replaced the array with random >accessing a large file instead. > I don't have an answer for Q2. The only sure answer are those compilers that support DOS Extenders (e.g. F77L/EM). Another suggestion is to split up large program segments into smaller ones. I once had a problem which sounds stupid. It was a canned routine which has many comments (comments/exe.statements = 1). Both MS and RM compilers refused to compile. I had to remove all of the comments before they compiled it successfully. Apparently, they keep everything, including comments, in memory. Once a 64KB segment is filled, an compiler error is generated. The idea here is to split up subroutines so that each one can fit into a 64KB segment. >-- >Stephen Quan, >University of Tasmania. > Tang Wong Yale University