Related articles |
---|
basic question about cps n.oje.bar@gmail.com (2012-11-12) |
Re: basic question about cps torbenm@diku.dk (2012-11-14) |
Re: basic question about cps monnier@iro.umontreal.ca (Stefan Monnier) (2012-11-14) |
Re: basic question about cps n.oje.bar@gmail.com (2012-11-21) |
From: | Stefan Monnier <monnier@iro.umontreal.ca> |
Newsgroups: | comp.compilers |
Date: | Wed, 14 Nov 2012 11:13:52 -0500 |
Organization: | A noiseless patient Spider |
References: | 12-11-004 |
Keywords: | analysis, code |
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
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).
Stefan
Return to the
comp.compilers page.
Search the
comp.compilers archives again.