Max size of a fortran procedure and max size of a line of code.

Max size of a fortran procedure and max size of a line of code.

I'm currently moving some optimizations from Mathematica to FORTRAN. The number of variables in each function range from 100s to 1000s so I would like to use Mathematica as a parser to write most of the FORTRAN code. Here are some questions:

1) What is the longest line of code that FORTRAN will accept?

For example, One of the functions is 3019244 characters long. Each gradient component is about 10,000 characters. I know FORTRAN 77 would not allow it, but will FORTRAN 2008 allow a procedure with one line of code 3019244 characters long?

2) There are similar calculations in the gradient and the function, should I explicitly code these calculations and stick them in a common block or can the compiler find them? Will I run into bandwidth problems with several hundred thousand variables (double precision reals) in the common block?

2b) Is there a max number of lines of code in a procedure and if so, what is it?

3) Some of the optimizations are Least Squares so they can be unrolled over the domain space, this saves a great deal of time in Mathematica but uses a great deal of memory for the bytecode, Is it better to let the compiler unroll these functions or should I explicitly code them.?(With the result of that the above example will be a 24690689 character line of code.)

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

1) The Fortran (not FORTRAN) standard specifies that the maximum length of a free-form source line is 132 characters. Intel Fortran accepts up to 2048 characters on a single line. For fixed-form source, characters after column 72 are ignored.  The standard allows 255 free-form continuation lines - Intel Fortran has no fixed limit on these, but will allow at least 511 of standard length.  I would say that a single line of code that is 30 million characters long exceeds the capability of Intel Fortran and probably most other compilers.

2) I don't know what you mean by "stick [calculations] in a common block". If you have lots of variables that you want visible to multiple routines, please make them module variables rather than COMMON.

2b) There is no fixed limit on the number of lines of code in a procedure.

3) I always recommend letting the compiler do optimizations such as unrolling. I will comment that extremely large procedures may inhibit some optimizations.

Steve - Intel Developer Support

Given a function that requires 3 MB of code to evaluate it, I think that you should make a feasibility analysis before attempting to implementing routines to evaluate the gradient. How are you ever going to verify that the calculated gradient is correct? What is the number of optimization variables? Are your computing resources adequate to find the optimum point in a reasonable amount of time? Is the RAM adequate?

In other words, simply because Mathematica can output code do not assume that you can use the output code to perform the optimization.

@Steve: sorry about the FORTRAN instead of Fortran. Firefox claimed it was spelled all caps. (Like my professor in 1985 spelled it.)

So the best option is to break the functions up to about 220 characters and use an accumulation variable. Thanks

By Common block, I meant a module, so you nailed it. As a general rule, I can only code in Fortran77, but I can write Fortran77 in C, C++, java, Mathematica, and Fortran95. Still trying to learn to write Fortran77 in Fortran2008, and in Cuda C.

@mecej4: I'm not going to calculate the gradient. I use Mathematica to generate the function based on analytic principals and then use Mathematica to calculate the gradient. The parser will  translate the functions to Fortran (easy with the FortranForm[ ] function) and then output them as procedures to txt files, or some other form VS2010 wants for input. (I may have to finally learn XML.)

See for more detail:  

http://reference.wolfram.com/mathematica/guide/ListingOfAllFormats.html

When expanded, the functions are all mufti-variable polynomials, so there is little doubt that Mathematica can calculate the gradients. But you are right. The functions are too big to code by hand. I have 64GB, a xeon E5-2687w, and a budget for a xeon phi 3120a if necessary. Compiled Mathematica (bytecode) can solve a 200 variable problem in about 3 days, so Intel Fortran can do more, faster. How much, I don't know yet, but  if you want, I'll update this thread with progress reports. Thanks.

Frank,

Is it possible to get Mathematica to group all these variables into arrays and then use vector calculations to simplify the process ?
This approach would appear to be much better for auditing and for describing within Mathematica.
If the problem can not be structured in this way, I can't imagine the logic in Mathematica that creates the resulting code.

John

Quote:

John Campbell wrote:

Frank,

Is it possible to get Mathematica to group all these variables into arrays and then use vector calculations to simplify the process ?
This approach would appear to be much better for auditing and for describing within Mathematica.
If the problem can not be structured in this way, I can't imagine the logic in Mathematica that creates the resulting code.

John

The nice linear functions are a result oh how I unroll the loops and estimate squared errors. So probably not possible.

Leave a Comment

Please sign in to add a comment. Not a member? Join today