Coding Efficiency

[phys137 at mailcity.com]

long time ago i even published something related to that. Then C++ was new
and the hope was that inlining [available in C++ but not in C] could change
that. Just for fun I took some programs - (not in C++) and did
semi-automatic inlining of leaves - some of them. the mean number of
instructions between jumps grew up 10 times(!). That was for the compiler.
For other programs (db, numerical) the numbers were above 5 times.

Looking at the same problem now I see the pipelining problem is unlikely to
get better - oo programming actively prevents you from inlining most of the
time. There may be some hope for functional languages - the higher the level
the better you can play with instructions (inlining, loop unrolling etc)


"Steve Williams" <sandj.williams at gte.net> wrote in message
news:3A5B6586.50B51F68 at gte.net...
> I saw this in an otherwise worthless thread on Slashdot about OOP:
>
>    Another reason ... (Score:5, Informative)
>            by taniwha on Tuesday January 09, @12:40PM EST (#54)
>            (User #70410 Info) http://www.taniwha.com/nospam.jpg
>            (for the record I first wrote smalltalk code in the 70's, I
> regularly code in C++ ...)
>
>            I'm a sometimes chip designer, sometimes programmer ... a
> while back while
>            working on an unnamed CPU project I did some low level
> performance analysis on
>            a number of well known programs (maybe even the browser
> you're using now)
>            basicly we were taking very long instruction/data traces and
> then modelling them
>            against various potential CPU pipeline/tlb/cache
> architectures - we were looking for
>            things that would help guide us to a better architecture for
> our CPU.
>
>            I found that quite early on I could figure out which language
> something was coded
>            in from the cooked numbers pretty easily - OO (ie C++) coded
> stuff always had a
>            really sucky CPI (clocks per instruction - a measure of
> architectural efficiency that
>            includes pipe breaks, stalls and cache misses) - I spent some
> time looking at this
>            (since it seemed that C++ code would probably become more
> common in our CPU's
>            lifetime) - basicly C++ code sucked because it took more
> icache hits (because the
>            coding style encourages lots of subroutine calls which tend
> to spread over the
>            cache more filling the I$ quickly) and it took more pipe
> breaks (also due to the
>            subrotine calls and returns - it turned out that some code
> generators did stuff that
>            broke CPU's return stack caches causing many more
> mispredicts) and finally virtual
>            method dispatches (basicly load a pointer, save the pc on the
> stack and jump to the
>            new pointer) tended to cause double pipe stalls that couldn't
> be predicted well at all
>            even though these weren't done much they were a real killer
> (if you've one a bit of
>            modern CPU architecture you learn that with long pipes you
> live or die on your
>            branch predictor's hit rate - these were very bad news)
>
>            In short C++ and more genrally OO result in code and coding
> styles that tend to
>            make code that makes modern CPU's run less efficiently.
>
>            Anyway - you often hear about 'efficiency of programmers' etc
> etc for OO - I
>            thought I'd add a data point from the other end of the
> spectrum.
>            [
>