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

Conference turris::fortran

Title:	Digital Fortran
Notice:	Read notes 1.* for important information
Moderator:	QUARK::LIONEL

Created:	Thu Jun 01 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1333
Total number of notes:	6734

1295.0. "Why are our fortran compilers so fast" by DV780::ENGQUIST (Eric Engquist) Mon May 12 1997 18:44

    Here is a question from an account at Sandia National Labs that is 
    looking at our systems verses SGI, SUN, etc.  The order will be for
    about 60 workstations.
    
    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.R	Title	User	Personal Name	Date	Lines
1295.1		QUARK::LIONEL	Free advice is worth every cent	`Mon May 12 1997 22:53`	10
	Well, we could slow our compiler down if it would make the customer happy.... We have a lot of experience in building fast Fortran compilers. Our C++ compiler is known to be slow, though you should find dramatic improvements there when the next major release comes out. Does the customer think we are "cheating" somehow? Steve
1295.2	Thanks, I will pass it on	DV780::ENGQUIST	Eric Engquist	`Tue May 13 1997 00:44`	4
	I don't think they think we are cheating, just curious. I told them about GEM and our Fortran experience, but then they hit me with what happened to C/C++.
1295.3		QUARK::LIONEL	Free advice is worth every cent	`Tue May 13 1997 09:52`	4
	What takes so long in C++ isn't GEM, it's the front end and the way it processes the program. That's what's being improved. Steve
1295.4		TLE::EKLUND	Always smiling on the inside!	`Tue May 13 1997 10:33`	17
	Having been involved in several interesting compiler performance issues, I can tell you that we have spent a lot of energy finding performance hot spots in the f77 compiler and fixing them. One very notable program (which processed about 1,900,000 lines of source (in a single compilation) went from days down to 22 minutes through a wide variety of improvements (I lost count how many things we changed). We get to see quite a number of huge applications, and we try to improve our algorithms to handle such monsters - many of us really enjoy this challenge, and feel that we want to have a compiler that really is "industrial strength"! Sometimes it takes a while to reach this state, but as Steve points out, we have been very successful in this area for quite some time - experience counts! Cheers! Dave Eklund
1295.5	Compiled so fast that make didn't pick up on it?	QUARRY::petert	rigidly defined areas of doubt and uncertainty	`Tue May 13 1997 10:58`	4
	Does this relate to the problem in make files that I saw over in the Digital Unix conference? PeterT
1295.6		TLE::EKLUND	Always smiling on the inside!	`Tue May 13 1997 11:43`	9
	I presume you mean note 9790 in the Unix conference. Amusing. Time to slow down those compilations... The thrust of that note is that compilations happen too quickly, such that there is some kind of problem in a makefile where the objects to NOT get picked up when they should. I've not looked at this (nor do I intend to!). Cheers! Dave Eklund
1295.7		QUARK::LIONEL	Free advice is worth every cent	`Tue May 13 1997 11:51`	5
	I think that for our next release we ought to look into adding Resublimated Thiotimoline technology (see "The Endochronic Properties of Resublimated Thiotimoline", Isaac Asimov) so that we can finish compiling before we start! Steve
1295.8	.5 - Yes same code	DV780::ENGQUIST	Eric Engquist	`Tue May 13 1997 16:55`	2
	.5 - Yes, it is the same code that has that problem.
1295.9	*.6 - Customer LOVES this problem	DV780::ENGQUIST	Eric Engquist	`Tue May 13 1997 16:57`	3
	.6 - No we don't want compilers slowed down, the LOVE the speed. However if it is a make issue, we need to get that fixed!
1295.10		TLE::EKLUND	Always smiling on the inside!	`Tue May 13 1997 17:46`	5
	Are these by any chance nfs mounted disks? Cheers! Dave Eklund
1295.11	Already checked into that	DV780::ENGQUIST	Eric Engquist	`Wed May 14 1997 23:50`	8
	They are not NFS mounted (I checked that as if they are not running ntp or such that would be a problem.) Also turned off KDEBUG and turned on MICRO_TIME to no avail. The code is mainly fortran 77 and C. Each time I run the make is doesn't get all the .o's into the archieve. I do have a tar of the code and can get it to someone. It is real weird. It just seems not to get all the .o's using the $? in ar.
1295.12		TLE::EKLUND	Always smiling on the inside!	`Mon May 19 1997 10:41`	8
	According to the latest response in the Unix conference, this may be related to a bug in msync. Apparently sometimes the modification times are not updated when they should have been... I think we should simply consider this to be a Unix problem until proven otherwise. Cheers! Dave Eklund