in gfortran, is it faster compile times with *.mod files ?

Post by Lynn McGuire
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?

I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).

In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

Not sure what you're asking for. Can you give an example?

Lynn McGuire

2024-11-11 23:09:32 UTC

Post by Lynn McGuire
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?

I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).
In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

Not sure what you're asking for. Can you give an example?

1. you compile abc.f in IVF
2. IVF automagically creates an abc__genmod.f90 file in your release
subdirectory with the subroutine / function module interface in it

Thanks,
Lynn

Thomas Koenig

2024-11-12 08:01:40 UTC

Post by Lynn McGuire
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?

I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).
In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

Not sure what you're asking for. Can you give an example?

1. you compile abc.f in IVF
2. IVF automagically creates an abc__genmod.f90 file in your release
subdirectory with the subroutine / function module interface in it

I think I get the general gist (but it would help me understand
if you could post a complete example).

But gfortran currently does not have such a feature (which appears
to duplicate modules). It is also not immediately clear what should
happen if, for example, a procedure uses a derived type from another
module... (This may not be relevant to your case, but as a compiler
writer, you have to think about this kind of thing :-|)

What would go wrong if you simply encapsulated abc.f in

MODULE ABC
CONTAINS
C Your code here
END MODULE ABC

?

Lynn McGuire

2024-11-12 20:07:16 UTC

Post by Lynn McGuire
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?

I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).
In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

Not sure what you're asking for. Can you give an example?

1. you compile abc.f in IVF
2. IVF automagically creates an abc__genmod.f90 file in your release
subdirectory with the subroutine / function module interface in it

I think I get the general gist (but it would help me understand
if you could post a complete example).
But gfortran currently does not have such a feature (which appears
to duplicate modules). It is also not immediately clear what should
happen if, for example, a procedure uses a derived type from another
module... (This may not be relevant to your case, but as a compiler
writer, you have to think about this kind of thing :-|)
What would go wrong if you simply encapsulated abc.f in
MODULE ABC
CONTAINS
C Your code here
END MODULE ABC
?

I am not sure what that would get me. I have 6,000+ subroutines and
functions in 5,000+ files. And I would still have to modify each file.

I am going to write a C++ program to put a USE statement in each
subroutine / function with the name of the subroutine / function to be
excluded. It should not take me more than a day or three.

I scanned through the Fortran Language doc but it did not have a USE
case for this.
https://j3-fortran.org/doc/year/24/24-007.pdf

Thanks,
Lynn McGuire

Thomas Koenig

2024-11-12 20:59:30 UTC

Post by Lynn McGuire
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?

I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).
In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

Not sure what you're asking for. Can you give an example?

1. you compile abc.f in IVF
2. IVF automagically creates an abc__genmod.f90 file in your release
subdirectory with the subroutine / function module interface in it

I think I get the general gist (but it would help me understand
if you could post a complete example).
But gfortran currently does not have such a feature (which appears
to duplicate modules). It is also not immediately clear what should
happen if, for example, a procedure uses a derived type from another
module... (This may not be relevant to your case, but as a compiler
writer, you have to think about this kind of thing :-|)
What would go wrong if you simply encapsulated abc.f in
MODULE ABC
CONTAINS
C Your code here
END MODULE ABC
?

I am not sure what that would get me.

Automated checking, according to the language definition. You might
even find a bug or 300.

Post by Lynn McGuire
I have 6,000+ subroutines and
functions in 5,000+ files. And I would still have to modify each file.

Yes.

Post by Lynn McGuire
I am going to write a C++ program to put a USE statement in each
subroutine / function with the name of the subroutine / function to be
excluded. It should not take me more than a day or three.
I scanned through the Fortran Language doc but it did not have a USE
case for this.
https://j3-fortran.org/doc/year/24/24-007.pdf

It is notoriously hard to read the standard if you want to find
anything in particular...

Hm... maybe another point. If you want to find discrepancies in
argument lists, you could concatenate all your Fortran source files
into one (which will be large, I presume) and then run "gfortran
-fsyntax-only" on it. You could then get error messages like

$ cat mismatch.f
subroutine foo(a)
real a
end

subroutine bar
call foo(42)
end
$ gfortran -fsyntax-only mismatch.f
mismatch.f:6:72:

6 | call foo(42)
| 1
Error: Type mismatch in argument 'a' at (1); passed INTEGER(4) to REAL(4)

which you could then investigate.

Lynn McGuire

2024-11-13 20:27:32 UTC

Post by Lynn McGuire
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?

I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).
In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

Not sure what you're asking for. Can you give an example?

1. you compile abc.f in IVF
2. IVF automagically creates an abc__genmod.f90 file in your release
subdirectory with the subroutine / function module interface in it

I think I get the general gist (but it would help me understand
if you could post a complete example).
But gfortran currently does not have such a feature (which appears
to duplicate modules). It is also not immediately clear what should
happen if, for example, a procedure uses a derived type from another
module... (This may not be relevant to your case, but as a compiler
writer, you have to think about this kind of thing :-|)
What would go wrong if you simply encapsulated abc.f in
MODULE ABC
CONTAINS
C Your code here
END MODULE ABC
?

I am not sure what that would get me.

Automated checking, according to the language definition. You might
even find a bug or 300.

Post by Lynn McGuire
I have 6,000+ subroutines and
functions in 5,000+ files. And I would still have to modify each file.

Yes.

It is notoriously hard to read the standard if you want to find
anything in particular...
Hm... maybe another point. If you want to find discrepancies in
argument lists, you could concatenate all your Fortran source files
into one (which will be large, I presume) and then run "gfortran
-fsyntax-only" on it. You could then get error messages like
$ cat mismatch.f
subroutine foo(a)
real a
end
subroutine bar
call foo(42)
end
$ gfortran -fsyntax-only mismatch.f
6 | call foo(42)
| 1
Error: Type mismatch in argument 'a' at (1); passed INTEGER(4) to REAL(4)
which you could then investigate.

Yeah, I really do not want to do that as it will be only a special run.
I want the errors to show up during each compile so that the programmer
will fix them right then and there.

And we had a user run into an unbalanced argument call to a subroutine
on Monday. One of us had changed a subroutine argument list and fixed 8
out of the 9 calls. No telling how many of those land mines are sitting
in our software.

Thanks,
Lynn McGuire

Thomas Koenig

2024-11-14 06:48:47 UTC

Post by Thomas Koenig
Hm... maybe another point. If you want to find discrepancies in
argument lists, you could concatenate all your Fortran source files
into one (which will be large, I presume) and then run "gfortran
-fsyntax-only" on it. You could then get error messages like
$ cat mismatch.f
subroutine foo(a)
real a
end
subroutine bar
call foo(42)
end
$ gfortran -fsyntax-only mismatch.f
6 | call foo(42)
| 1
Error: Type mismatch in argument 'a' at (1); passed INTEGER(4) to REAL(4)
which you could then investigate.

Yeah, I really do not want to do that as it will be only a special run.
I want the errors to show up during each compile so that the programmer
will fix them right then and there.

Then modules are your best choice, I think.

On the other hand, -fsyntax-only is very fast because it does not
do code generation at all. It might be worth a try to see how
long it takes on your whole codebase, and if it can be integrated
into your normal compilation process.

Post by Lynn McGuire
And we had a user run into an unbalanced argument call to a subroutine
on Monday. One of us had changed a subroutine argument list and fixed 8
out of the 9 calls. No telling how many of those land mines are sitting
in our software.

You will find out with -fsyntax-only. Another possibility is -flto, but
then the final "linking" step will take a very long time. Might speed
up things in the resulting executable, though.

Lawrence D'Oliveiro

2024-11-11 22:54:24 UTC

Post by Lynn McGuire
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?

gfortran already does .mod files.

Lynn McGuire

2024-11-12 00:32:28 UTC