[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:DECC
Notice:General DEC C discussions
Moderator:TLE::D_SMITHNTE
Created:Fri Nov 13 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2212
Total number of notes:11045

2183.0. "Why Fortran so fast, c, c++ slow?" by DV780::ENGQUIST (Eric Engquist) Mon May 12 1997 18:47

    I am working with a group with our systems verses HP, SUN, SGI, etc.
    This order is worth about 60 workstations.  The group is at Sandia
    National Labs and here is an issue they have noticed.
    
    They love compling, most of there work is compiling code.  So part
    of this benchmark is to see how fast the code compiles for some F77
    code
    and some C and C++ code.  Again this is being evaluated for compile
    time vs SGI, SUN and HP.  They want to know why our f77 compiler is
    so fast.  For example, a SUN multiprocessor takes 922 seconds to 
    comile the fortran suite, the 433au does it in 92 seconds.  We are
    10 times as fast and they want to know why.  On c++ compiles we
    are slower than the sun (twice as slow).  On running the code we are
    faster
    but not the 10x difference (like 2x).  I know we use the GEM technology
    on f77
    but we also use it on C.  Anyone explain why we are so much faster?
    
                                            -Eric Engquist
                                             [email protected] (SNL address)
                                             [email protected] (DEC address)
    
                                             (505) 844-0974 (SNL)
                                             (505) 343-7252
T.RTitleUserPersonal
Name
DateLines
2183.1need more infoDECC::OUELLETTEmudseason into blackfly seasonMon May 12 1997 20:3817
The short answer is that the difference must lie in the different Fortran
and C frontends.  A lot may depend upon the version of the C or C++
compiler; which version is getting complaints?  We know we have problems
with some codes and our current version of our C++ compiler.  Preliminary
results with preliminary versions of what will be the V6.0 C++ compiler are
much better on code that needs to instantiate templates.

We too are very conserned about compile time speed, but do they *really*
spend *all* day compiling, or do they eventually need to run their code?
And what does their C and C++ code look like?  Is their problematic code
C++ only or do they have problem with C also (this would be news to us and
we'd like to see sample code).

We'd need a whole lot more information to diagnose a compile time problem
definitively.  We've done such work before and can do it again.

Roland.
2183.2Will get more info.DV780::ENGQUISTEric EngquistTue May 13 1997 00:424
    I will have to check and see.  I didn't load the compilers.  The
    system is a 433au running Digital Unix 4.0C.  I will get back to your
    on this.
    
2183.3need MUCH more info :-)DECC::MDAVISMark Davis - compiler maniacTue May 13 1997 10:5243
>>    They love comp[i]ling,

So they must REALLY love our c++, since we let them spend more TIME
compiling...

1. what is the compiler version.  Is it just c++ that is slow, or
c too?

2. what are the compiler options used, e.g., is debugging turned on;
what opt level?  (Sun does their debugging info differently than
we do.)

3. Is the "compile time" cpu time or elapsed time; and is it time to
run the compiler, or to compile AND link?

4. Does the c++ code use lots of templates?  Auto template instantiation
requires several rounds of: compile the .cxx files, trial link looking
for unresolved references, compile files from cxx_repository to 
instantiate templates, trial link, etc.

5. c++ programs typically have zillions of tiny routines - each one is
passed all the way through GEM before the next one (this is a slight lie,
but close enough).  In contrast, Fortran programs usually have a few, LARGE
routines. GEM's structure is designed to crunch on a large mouthful of
program, not on miniscule snacks.

6. If you compile using "-source_listing -show statistics" you will get
something like:
COMPILATION STATISTICS

  CPU time:          0.01 seconds
  Elapsed time:      0.06 seconds
  Pagefaults:           0
  I/O Count:            6
  Source lines:         3

  18000 lines per CPU minute.

It would be interesting to compare the "lines per minute" with the 
fortran compiles (f77 -V ).

Mark Davis
c/c++ team
2183.4DEC C V5.2 on Digital UNIX V4.0C, latest DEC C++DECC::SULLIVANJeff SullivanTue May 13 1997 13:2215
The default C compiler for Digital UNIX V4.0C is DEC C V5.2, with GEM BL31
backend. We'd be interested in both compile- and run-time bottlenecks, if you
can provide details. There is a field test version of DEC C V5.6, with GEM BL33
available via the web at http://www.zk3.dec.com/decc/decc-kitinfo.html. It is
ecpected that the later GEM backend should produce better run-time performance.
The final version of this compiler is expected to be delivered on V4.0D.

The latest SSB DEC C++ compiler for Digital UNIX V4.0C is V5.5 and is found on
the layered product CD. A field test version of V5.6 is available (DEC C++
T5.6-006, FT2), which contains some enhancements over V5.5; including compress
object files. See TURRIS::C_PLUS_PLUS Note 3546 or
http://www.zk3.dec.com/decc/decc-kitinfo.html if you are interested in the field
test DEC C++ compiler.

-Jeff
2183.5DECCXL::OUELLETTEmudseason into blackfly seasonTue May 13 1997 14:185
There has been lots of work since DEC C V5.2.
Several fairly major C compile time performance problems have been
solved since then.  Trying the field test V5.6 would be interesting
as would trying whatever cc.alt is on Digital UNIX V4.0C (It's newer
than the default cc compiler -- DEC C V5.3, V5.4 or V5.5 (I don't know which)).
2183.6Thanks foir the answersDV780::ENGQUISTEric EngquistWed May 14 1997 23:456
    Thanks for your answers.  The customer did not feel that we were
    slow, it just wasn't the magintude of the fortran compiles.
    They were using C++ version 5.5.  They did purchase about 10
    of the au series, but because adobe is saying the next version
    of framemaker would not run on dux, they are buying 60 SUNs.  However
    we did impress them enought that we did get a foot in the door.