- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, in my application I have some files that contain many subroutines. In doing a search for a string (typically a variable name) the Find feature of the software lists the results and whilst giving the line number in the file does not list the subroutine name. This might be a useful feature to include in future versions of the software?
Thanks,
Angus.
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'd suggest you break the 'file with many subroutines' into many files with a subroutine each. there are utilities for doing this if if is many many routines (can't think of them offhand but i know of several so let me know if you'd like names of some) There is no reason to have them all in one file.
brian
brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Multiple subroutines in a single file are subject to inter-procedural analysis by default. Depending on your application, the compile time, or possible effects of exceeding optimization limits, may out-weigh the performance benefits. When building under Visual Studio or make, the ability to update individual subroutines may save a great deal of time.
The traditional fsplit program for f77 code (legacy C source code) remains in wide usage. f90split (Fortran source code( is a popular one which accepts f90 as well as f77.
The traditional fsplit program for f77 code (legacy C source code) remains in wide usage. f90split (Fortran source code( is a popular one which accepts f90 as well as f77.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bmchenty and TimP,
The suggestion of ungrouping my subroutines into seperate files seems a little radial on first reading. The reason for grouping is both logical and also I am beginning to convert them into modules, i.e.
MODULE BORIS
.
CONTAINS
.
SUBROUTINE BORISSON
.
END SUBROUTINE
END MODULE
I have assumed that this is the way to go in programming in FORTRAN but now I am hearing that there may be performance benefits to be had by not doing this? I have spotted the compile time creep up as my application grows but thought that this was simply a size issue rather than a file storage one.
My initial question was actually a little different, i.e. it was a suggestion to Intel to enhance the search capability within a single file but I am interested in best practice and so wonder whether I really do need to split up my code in this manner?
Thanks,
ACAR.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you are doing (grouping files into modules) is a good idea. I can't comment on the compile time issue.
The search facility, I believe is a feature of Visual Studio rather than Fortran, and the "problem" (of not reporting which subroutine the find has occured in) is true of all languages.
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Taking advantage of MODULE facility lends itself to putting those functions into USE files. I don't believe the degree of interprocedural analysis which ifort undertakes in that case is directly comparable to what is done with legacy single file code. When you get organized to take advantage of .mod files, this should save you time on partial recompilation.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page