Re: When/why did function calls get cheap?

John Plevyak <jplevyak@yahoo.com>
21 Feb 2003 01:21:10 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: When/why did function calls get cheap? bje@redhat.com (Ben Elliston) (2003-02-21)
Re: When/why did function calls get cheap? joachim_d@gmx.de (Joachim Durchholz) (2003-02-21)
Re: When/why did function calls get cheap? marcov@toad.stack.nl (Marco van de Voort) (2003-02-21)
Re: When/why did function calls get cheap? firefly@diku.dk (Peter Finderup Lund) (2003-02-21)
Re: When/why did function calls get cheap? firefly@diku.dk (Peter Finderup Lund) (2003-02-21)
Re: When/why did function calls get cheap? anton@mips.complang.tuwien.ac.at (2003-02-21)
Re: When/why did function calls get cheap? jplevyak@yahoo.com (John Plevyak) (2003-02-21)
Re: When/why did function calls get cheap? {spamtrap}@qeng-ho.org (Arthur Chance) (2003-02-24)
Re: When/why did function calls get cheap? gah@ugcs.caltech.edu (Glen Herrmannsfeldt) (2003-02-24)
Re: When/why did function calls get cheap? alexc@std.com (Alex Colvin) (2003-02-24)
Re: When/why did function calls get cheap? vbdis@aol.com (2003-02-24)
Re: When/why did function calls get cheap? firefly@diku.dk (Peter Finderup Lund) (2003-03-09)
Re: When/why did function calls get cheap? joachim_d@gmx.de (Joachim Durchholz) (2003-03-09)
[7 later articles]
| List of all articles for this month |

From: John Plevyak <jplevyak@yahoo.com>
Newsgroups: comp.compilers
Date: 21 Feb 2003 01:21:10 -0500
Organization: Prodigy Internet http://www.prodigy.com
References: 03-02-073
Keywords: architecture, practice
Posted-Date: 21 Feb 2003 01:21:10 EST

Peter Seibel wrote:
> My understanding is that in Olden Times, Real Programmers avoided
> using lots of small functions because the overhead of a function call
> was considered high. But then, somewhere along the way, the compiler
> writers got clever and made function calls cheap so now nobody worries
> about it.


In addition to speed, changes in computer architecture have
also had their effect:


1) Instruction cache misses are very expensive, so if you 'inline'
        either manually or automatically too much code and blow out the
        i-cache the program may run slower than if the program
        used functions to share code.


2) Branch prediction coupled with speculative execution, out of order
        execution and register renaming can effectively make a lot of
        the boiler-plate function-call work/instructions cheap compared
        to an i-cache miss or branch predition failure.


3) Branch prediction works best on repeated code sequences and
        static targets (for example function calls).
        The branch prediction unit has a finite size
        and must 'guess' the first time it sees a branch. This can
        be a problem for excessive inlining. Also, failed branch
        preditions are expensive on deeply pipelined architectures.
        A failed branch prediction can even exacerbate the i-cache problem
        since the instruction prefetch will not be able to hide the memory
        latency.


In other words, the cost model for modern computers is different
than it was 25 years ago as well. Locality (cachability) and
predictability are more important than pure instruction counts.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.