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).