|basic question about cps firstname.lastname@example.org (2012-11-12)|
|Re: basic question about cps email@example.com (2012-11-14)|
|Re: basic question about cps firstname.lastname@example.org (Stefan Monnier) (2012-11-14)|
|Re: basic question about cps email@example.com (2012-11-21)|
|From:||Stefan Monnier <firstname.lastname@example.org>|
|Date:||Wed, 14 Nov 2012 11:13:52 -0500|
|Organization:||A noiseless patient Spider|
|Posted-Date:||15 Nov 2012 00:05:17 EST|
> 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
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).
Return to the
Search the comp.compilers archives again.