Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end
From: n.oje.bar@gmail.com
Newsgroups: comp.compilers
Subject: Re: basic question about cps
Date: Wed, 21 Nov 2012 09:27:46 -0800 (PST)
Organization: Compilers Central
Lines: 30
Sender: johnl@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <12-11-011@comp.compilers>
References: <12-11-004@comp.compilers> <12-11-010@comp.compilers>
NNTP-Posting-Host: news.iecc.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: leila.iecc.com 1353524683 82435 64.57.183.58 (21 Nov 2012 19:04:43 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Wed, 21 Nov 2012 19:04:43 +0000 (UTC)
Keywords: analysis, administrivia
Posted-Date: 21 Nov 2012 14:04:43 EST
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:782

On Wednesday, November 14, 2012 4:13:52 PM UTC, Stefan Monnier wrote:
> > It seems to me that if one performs the cps transformation one is left
> > with many 'computed' calls (that is call to variables holding
> > procedure values, namely, the continuation).
>
> Yes.  Every additional "computed call" (aka indirect call) corresponds
> to a "return" in the non-CPS version of the code.
>
> > It seems that compiling such 'computed' calls would be much slower
> > than compiling 'direct' calls to known procedures.
>
> That's the wrong comparison: the non-CPS version wouldn't see direct
> calls there, but would see `return's instead.

> Also, you're talking about "compiling" being "slower": are you really
> concerned about the speed of compilation, or the speed of the
> generated code?

> The performance of "return" versus "indirect call" depends on many
> factors, but it's probably important to try and make sure that the
> "return-like indirect calls" are compiled to code which the CPU
> recognizes as "some sort of return", in order for the
> branch-prediction to work better (CPUs keep an internal&hidden stack
> to try and predict the destination of return instructions).

Thanks very much for all your replies!

Best regards,
Nicolas