Newsgroups: comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!mckinley!rob
From: rob@mckinley.eng.ohio-state.edu (Rob Carriere)
Subject: Re: low level optimization
Message-ID: <1991Apr28.185714.22202@ee.eng.ohio-state.edu>
Sender: news@ee.eng.ohio-state.edu
Organization: The Ohio State University Dept of Electrical Engineering
References: <21818@lanl.gov> <3905@inews.intel.com> <20270@alice.att.com>
Date: Sun, 28 Apr 1991 18:57:14 GMT

In article <20270@alice.att.com> wilber@homxb.att.com writes:
>Cross procedural optimization within a module doesn't buy you as much as you
>might hope; simply knowing that none of the calls to foo() within foo.c alias
>the parameters doesn't help if foo() is declared external (the default) because
>some call to foo() in another module might alias the parameters.  And I'd say
>that less than 10% of all functions in typical C code are declared static.
>(Even when functions aren't called outside of their modules, programmers rarely
>bother to declare them static.)

Well, the idea behind C has always been "the programmer knows what s/he is
doing."  Since that programmer _should_ have declared those fns static, I
don't see where I should be bothered by the fact that not doing so may inhibit
optimization.  

>Right now, in the Real World (TM), optimized Fortran really does run faster
>than optimized C.  A situation that truly sucks.

It seems to me that, like mister Giles, you are confusing properties of the
language with properties of the implementation.  It would sure be nice to have
those wonderful compilers today, but their presence or absence has nothing to
do with the merits or lack thereof of the language C.

SR
---