[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for Clarification on Rationale
* From: Shiro Kawai <shiro@xxxxxxxx>
* Date: Thu, 06 Apr 2006 14:01:48 -1000 (HST)
* Subj: Re: Request for Clarification on Rationale
| I feel this comparison is somewhat skewed. The typical
| situation where I use multiple values is:
| - multiple values are generated for every iteration,
| so mm vs vv test is more close, and
| - the expression body of generating multiple values are
| known, so I'd rather use srfi-8's RECEIVE.
| And this is the result on Gauche 0.8.6 / P4 2GHz (I use 100times
| more iterations as William Clinger did.)
gosh> (time (for-each (lambda (x) ((mm x) list)) (make-list 10000000
| ; real 19.542
| ; user 19.480
| ; sys 0.060
gosh> (time (for-each (lambda (x) (call-with-values (lambda () (vv
x)) list)) (make-list 10000000 1)))
| ; real 26.579
| ; user 26.460
| ; sys 0.110
gosh> (time (for-each (lambda (x) (receive z (vv x) (list z)))
(make-list 10000000 1)))
| ; real 11.805
| ; user 11.750
| ; sys 0.040
| The point is that the 'call-with-values' version creates
| a closure for every iteration, as well as mu version, while
| 'receive' version can optimize it away. The same optimization
| is done with srfi-11 let-values as well.
| (If the optimizer is sufficienty smart, 'call-with-values'
| version can also be compiled without creating closures,
| given that the binding of 'call-with-values' itself is
| not altered elsewhere.)
| The difference of mu vs call-with-values did catch my
| attention. There should be some room for improvement.
Have you done the test in other implementations?