Afficher les réponses par date
Date: Mon, 25 Jun 2007 13:27:15 -0700 From: "naruto canada" narutocanada@gmail.com
Does gambit-c have call/ec? Thanks.
It might help if you explained what this non-standard procedure is supposed to mean.
On 6/27/07, Taylor R Campbell campbell@mumble.net wrote:
It might help if you explained what this non-standard procedure is supposed to mean.
It's `call-with-escape-continuation', a procedure that PLT Scheme provides because their implementation of full continuations isn't staggeringly efficient.
--Jeff
On 6/27/07, Taylor R Campbell campbell@mumble.net wrote:
Date: Mon, 25 Jun 2007 13:27:15 -0700 From: "naruto canada" narutocanada@gmail.com
Does gambit-c have call/ec? Thanks.
It might help if you explained what this non-standard procedure is supposed to mean.
I don't really understand call/cc or call/ec to be honest. All I know is that I only use call/cc for "early abort (return)" purpose. (also for "amb"). Someone from comp.lang.scheme suggests I use call/ec. I get a good improvement with mzscheme so I am wondering if gambit-c has the same function.
You can look at this thread: http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/ec14608...
On 27-Jun-07, at 11:52 AM, naruto canada wrote:
I don't really understand call/cc or call/ec to be honest. All I know is that I only use call/cc for "early abort (return)" purpose. (also for "amb"). Someone from comp.lang.scheme suggests I use call/ec. I get a good improvement with mzscheme so I am wondering if gambit-c has the same function.
You can look at this thread: http://groups.google.com/group/comp.lang.scheme/browse_thread/ thread/ec1460818c10971f/f9640e6e9396dcac#f9640e6e9396dcac
I've briefly looked at your code. It appears that you are running the code (accu.sc) *interpreted* (your file top.sc, which you do compile, is a read-eval-print loop which calls eval, so the code from accu.sc which you pipe to "top" will be interpreted). You should get much better performance with Gambit if you compile the accu.sc program directly with gsc.
Marc
On 25-Jun-07, at 4:27 PM, naruto canada wrote:
Does gambit-c have call/ec? Thanks.
Call/ec is not predefined. You can define it yourself like this:
(define call/ec call/cc)
Obviously, in this case the implementation of call/ec is not as fast as it could be. On the other hand, Gambit's implementation of continuations is one of the most efficient. For example, on the ctak benchmark which uses call/cc extensively, Gambit is about 2 orders of magnitude faster than MzScheme. It would be interesting to see how MzScheme fairs when call/cc is replaced by call/ec in that benchmark (I can't run the test because my usual work machine is out of order). See http://www.iro.umontreal.ca/~gambit/bench.html for other benchmark results (fibc also uses continuations extensively).
Marc
On Jun 27, 2007, at 8:35 AM, Marc Feeley wrote:
On 25-Jun-07, at 4:27 PM, naruto canada wrote:
Does gambit-c have call/ec? Thanks.
Call/ec is not predefined. You can define it yourself like this:
(define call/ec call/cc)
Obviously, in this case the implementation of call/ec is not as fast as it could be.
Marc:
Is there some combination of continuation-capture and continuation- graft that gives the semantics of call/ec?
To be honest, I don't understand what any of call/ec, continuation- capture, and continuation-graft do.
Brad
Bradley Lucier wrote:
On Jun 27, 2007, at 8:35 AM, Marc Feeley wrote:
On 25-Jun-07, at 4:27 PM, naruto canada wrote:
Does gambit-c have call/ec? Thanks.
Call/ec is not predefined. You can define it yourself like this:
(define call/ec call/cc)
Obviously, in this case the implementation of call/ec is not as fast as it could be.
Marc:
Is there some combination of continuation-capture and continuation- graft that gives the semantics of call/ec?
To be honest, I don't understand what any of call/ec, continuation- capture, and continuation-graft do.
In my honest experience:
##continuation-capture is just call/cc but gives the raw continuation data type without wrapping as a procedure. (It's a bit faster because of this.)
##continuation-graft (there is no |continuation-graft|, right, or has this been added recently?) is quite nifty, it runs the given thunk in the context of a given continuation (it needs the raw continuation as given by ##continuation-capture). See http://scheme.mine.nu/gambit/scratch/cj-exception/ for an example (the idea of this module is to provide exception values which are restartable later, e.g. to be serialized and stored to disk and provided for debugging later on). Actually you should use the -with-winding functions as shown so that dynamic-wind works. What the shown code does: capture the (raw) continuation from where an exception happened, wrap it together with the exception value in a cj-exception structure, and call the user-provided exception handler with it in the context of the code outside of the with-exception/continuation-catcher (e.g. the dynamic environment from outside has already been reinstantiated and exceptions thrown from |handler| will thus call the next outer current-exception-handler instead of looping into the inner one).
As far as I understand, call/ec would return a continuation which can only be instantiated once and only from the dynamic scope of their capture (like exceptions in languages without 1st class continuation support).
Christian.
On Jun 27, 2007, at 10:32 AM, Bradley Lucier wrote:
Marc:
Is there some combination of continuation-capture and continuation- graft that gives the semantics of call/ec?
Yes, since call/cc is built on top of the continution-XXX primitives and the following is a valid definition of call/ec:
(define call/ec call/cc)
The thing is that this implementation does not take advantage of the usage constraints of call/ec . It would be possible to implement call/ec in such a way that it does minimal heap allocation.
To be honest, I don't understand what any of call/ec, continuation- capture, and continuation-graft do.
Check out my paper "A Better API for First-Class Continuations" (http://repository.readscheme.org/ftp/papers/sw2001/ feeley.ps.gz) for the continuation-XXX operations.
Marc
On Jun 27, 2007, at 8:35 AM, Marc Feeley wrote:
On 25-Jun-07, at 4:27 PM, naruto canada wrote:
Does gambit-c have call/ec? Thanks.
Call/ec is not predefined. You can define it yourself like this:
(define call/ec call/cc)
Obviously, in this case the implementation of call/ec is not as fast as it could be. On the other hand, Gambit's implementation of continuations is one of the most efficient. For example, on the ctak benchmark which uses call/cc extensively, Gambit is about 2 orders of magnitude faster than MzScheme. It would be interesting to see how MzScheme fairs when call/cc is replaced by call/ec in that benchmark (I can't run the test because my usual work machine is out of order). See http://www.iro.umontreal.ca/~gambit/bench.html for other benchmark results (fibc also uses continuations extensively).
On a 1.66GHz Intel Core Duo Mac Mini, I just tried ctak and fibc on MzScheme v370 with call/cc and call/ec and I get these relative execution times:
Gambit MzScheme MzScheme call/cc call/cc call/ec ctak 1.0 113.6 7.1 fibc 1.0 56.1 5.5
So call/ec improves the MzScheme execution times by an order of magnitude. The resulting performance is still quite far from using plain call/cc with Gambit-C.
Marc
-
Bradley Lucier -
Christian Jaeger -
Jeff Read -
Marc Feeley -
naruto canada -
Taylor R Campbell