public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/40958] New: module files too large
@ 2009-08-04 9:02 jv244 at cam dot ac dot uk
2009-08-04 9:10 ` [Bug fortran/40958] " steven at gcc dot gnu dot org
2009-08-04 10:13 ` jv244 at cam dot ac dot uk
0 siblings, 2 replies; 3+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-08-04 9:02 UTC (permalink / raw)
To: gcc-bugs
I notice that the module files gfortran generates are really large, and believe
that this could maybe be improved easily, which would reduce disk usage and
presumably improve compile time.
The observation is that a compilation of CP2K generates 130Mb of .mod files for
27Mb sources. Doing a 'cat *.mod > modall' and using that file for analysis, I
find that 'bzip2 modall' -> 6Mb file, so 20-fold compression. Compile time
seems to also have a large factor of system time which is presumably disk
access. With a single process on a fast RAID disk, I get the following time:
> gfortran -c -fsyntax-only -ftime-report CP2K_2009-05-01.f90
Execution times (seconds)
garbage collection : 8.20 ( 7%) usr 0.34 ( 1%) sys 9.33 ( 4%) wall
0 kB ( 0%) ggc
callgraph construction: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
rebuild jump labels : 1.13 ( 1%) usr 0.11 ( 0%) sys 1.32 ( 1%) wall
7 kB ( 0%) ggc
parser : 80.34 (64%) usr 27.25 (88%) sys 157.87 (74%) wall
1272352 kB (34%) ggc
inline heuristics : 4.58 ( 4%) usr 0.42 ( 1%) sys 5.63 ( 3%) wall
38 kB ( 0%) ggc
tree gimplify : 7.69 ( 6%) usr 0.71 ( 2%) sys 9.73 ( 5%) wall
724206 kB (19%) ggc
tree eh : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.42 ( 0%) wall
0 kB ( 0%) ggc
tree CFG construction : 1.55 ( 1%) usr 0.18 ( 1%) sys 2.05 ( 1%) wall
388675 kB (10%) ggc
tree CFG cleanup : 0.46 ( 0%) usr 0.03 ( 0%) sys 0.53 ( 0%) wall
1901 kB ( 0%) ggc
dominance computation : 0.25 ( 0%) usr 0.03 ( 0%) sys 0.42 ( 0%) wall
0 kB ( 0%) ggc
expand : 19.47 (16%) usr 1.82 ( 6%) sys 24.43 (11%) wall
1348665 kB (36%) ggc
varconst : 0.02 ( 0%) usr 0.01 ( 0%) sys 0.06 ( 0%) wall
263 kB ( 0%) ggc
final : 0.16 ( 0%) usr 0.02 ( 0%) sys 0.16 ( 0%) wall
0 kB ( 0%) ggc
symout : 0.03 ( 0%) usr 0.02 ( 0%) sys 0.05 ( 0%) wall
32 kB ( 0%) ggc
TOTAL : 124.67 31.08 212.75
3736334 kB
so a relatively large fraction of compile time is system time in the parser
(cpu usage during compilation is also rather far from 100%). Presumably a
parallel compile would be even more impacted.
While I don't have a good general solution, a nearly 50% improvement in mod
file size can be easily obtained by by-hand compression:
cat modall | sed "s/UNKNOWN/U/g" | sed "s/INTEGER/I/g" | sed "s/VARIABLE/V/g" |
sed "s/PROCEDURE/P/g" | sed "s/DERIVED/D/g" | sed "s/CHARACTER/C/g" | sed
"s/SUBROUTINE/S/g" | sed "s/FUNCTION/F/g" | sed "s/ASSUMED_SHAPE/AS/g" | sed
"s/REAL/R/g" | sed "s/CONSTANT/CST/g" | sed "s/DIMENSION/M/g" | sed
"s/DUMMY/Y/g" | sed "s/LOGICAL/L/g" | sed "s/EXPLICIT/X/g" | sed "s/INTENT/T/g"
| sed "s/ACCESS/XS/g" | sed "s/POINTER/PT/g" | sed "s/DEFERRED/FR/g" >
modall.new
yields a 75Mb file (so roughly half of the original). Presumably that would
reduce the time needed to read the mod files by half, and might be faster to
parse. The down-side is that the module files are somewhat harder
human-readable, but that can't be their primary purpose. Looking at module.c,
such a change would be relatively easy to implement.
--
Summary: module files too large
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/40958] module files too large
2009-08-04 9:02 [Bug fortran/40958] New: module files too large jv244 at cam dot ac dot uk
@ 2009-08-04 9:10 ` steven at gcc dot gnu dot org
2009-08-04 10:13 ` jv244 at cam dot ac dot uk
1 sibling, 0 replies; 3+ messages in thread
From: steven at gcc dot gnu dot org @ 2009-08-04 9:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from steven at gcc dot gnu dot org 2009-08-04 09:10 -------
Yup
--
steven at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-08-04 09:10:35
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug fortran/40958] module files too large
2009-08-04 9:02 [Bug fortran/40958] New: module files too large jv244 at cam dot ac dot uk
2009-08-04 9:10 ` [Bug fortran/40958] " steven at gcc dot gnu dot org
@ 2009-08-04 10:13 ` jv244 at cam dot ac dot uk
1 sibling, 0 replies; 3+ messages in thread
From: jv244 at cam dot ac dot uk @ 2009-08-04 10:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from jv244 at cam dot ac dot uk 2009-08-04 10:13 -------
It looks like also module.c contains minit calls that need to be modified. But
for a 50% savings in module size, that seems still a localized effort
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-08-04 10:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-04 9:02 [Bug fortran/40958] New: module files too large jv244 at cam dot ac dot uk
2009-08-04 9:10 ` [Bug fortran/40958] " steven at gcc dot gnu dot org
2009-08-04 10:13 ` jv244 at cam dot ac dot uk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).