FWIW,
1) the timings with the 32 bit version of Racket 5.3 (the other timings
were from the 64 bit version)
fibo-clos : cpu time: 12529 real time: 12720 gc time: 850
fibo-gen1 : cpu time: 21003 real time: 22319 gc time: 1808
fibo-gen2 : cpu time: 20527 real time: 20929 gc time: 1795
fibo-delay
On 08/10/2012 01:23, Danny Yoo wrote:
Hmmm! Looking at it now... Wait: your definition of fibo-gen2 is not
exactly equivalent to the others in terms of work when verbose is off.
Good spot! It's consistent now. Generators and delay/force are roughly
the same speed (although the latter explod
On Sun, Oct 7, 2012 at 11:34 AM, Patrick Useldinger
wrote:
> Hi,
>
> following up on my earlier thread (sep 16th) on the same subject, I tried to
> compare some solutions generating fibonacci series in a lazy way: via a
> closure, via generators and using delay/force.
Hmmm! Looking at it now...
At Tue, 18 Sep 2012 21:05:57 -0400, Eli Barzilay wrote:
> 10 minutes ago, Matthew Flatt wrote:
> > At Tue, 18 Sep 2012 20:46:40 -0400, Eli Barzilay wrote:
> > > A few minutes ago, Matthew Flatt wrote:
> > > >
> > > > Using `call/cc' for generators is effectively a hint to the run-time
> > > > syst
On Tue, Sep 18, 2012 at 12:59 PM, John Clements
wrote:
>
> On Sep 18, 2012, at 5:28 AM, Matthew Flatt wrote:
>
>> Meanwhile, it might be interesting to try implementing a `generator'
>> form that rewrites its body to implement `yield's that are
>> syntactically apparent (after local-expansion), le
10 minutes ago, Matthew Flatt wrote:
> At Tue, 18 Sep 2012 20:46:40 -0400, Eli Barzilay wrote:
> > A few minutes ago, Matthew Flatt wrote:
> > >
> > > Using `call/cc' for generators is effectively a hint to the run-time
> > > system that the continuation doesn't need to compose. That hint is
> > >
At Tue, 18 Sep 2012 20:46:40 -0400, Eli Barzilay wrote:
> A few minutes ago, Matthew Flatt wrote:
> >
> > Using `call/cc' for generators is effectively a hint to the run-time
> > system that the continuation doesn't need to compose. That hint is
> > useful only because of the way that continuation
A few minutes ago, Matthew Flatt wrote:
>
> Using `call/cc' for generators is effectively a hint to the run-time
> system that the continuation doesn't need to compose. That hint is
> useful only because of the way that continuations are implemented
> internally.
So `call/cc' is faster than one o
At Tue, 18 Sep 2012 19:20:29 +0200, Sam Tobin-Hochstadt wrote:
> continuations are *not* used to
> implement `thread` and associated facilities in Racket
Although Racket threads are not implemented with continuations in the
sense of `continuation?', both threads and continuations use the same
inte
p.s. Actually the closest to the simple producer function is this
buffer generator:
;; TO-DO: macro-ize
(define buffer-generator
(let* ([xs '()]
[ready? #f]
[yield (lambda (x) (set! xs (cons x xs)))])
(lambda ()
(unless ready?
;; --> User code here
(fo
On Tue, Sep 18, 2012 at 6:52 PM, Greg Hendershott
wrote:
>> I agree with others that the cost of capturing continuations is the
>> culprit in this case. The run-time system has support for faster
>> continuations that work in constrained settings (currently used to
>> implement futures), and it mi
On Sep 18, 2012, at 5:28 AM, Matthew Flatt wrote:
> I don't think the parameter overhead is relevant. In Jay's post, he
> performs 100k parameter accesses, and it takes 16 milliseconds; we can
> reasonably extrapolate 160 msec for 1M accesses. Patrick's generator
> example yields 1M times, and ta
> I agree with others that the cost of capturing continuations is the
> culprit in this case. The run-time system has support for faster
> continuations that work in constrained settings (currently used to
> implement futures), and it might be possible to make those
> continuations kick in work for
I don't think the parameter overhead is relevant. In Jay's post, he
performs 100k parameter accesses, and it takes 16 milliseconds; we can
reasonably extrapolate 160 msec for 1M accesses. Patrick's generator
example yields 1M times, and takes 18 seconds --- 100x the parameter
overhead.
I agree wit
An hour ago, Greg Hendershott wrote:
> In generator.rkt I notice an early version that didn't support
> multiple values. The new version does, keeping a "yielder" proc in a
> parameter.
>
> Could a single-valued generator yield be faster enough? Or am I
> misapplying my misunderstanding? :)
That
This stuff is still over my head; I'm at that "know just enough to be
dangerous" stage. With that caveat:
Jay's blog post
http://jeapostrophe.github.com/blog/2012/07/25/cont-marks2/ mentions
that parameters can be >10X slower than dynamic-wind.
In generator.rkt I notice an early version that didn
On 18/09/2012 00:24, Matthias Felleisen wrote:
On Sep 16, 2012, at 2:36 PM, Patrick Useldinger wrote:
Which makes me wonder if continuations are really usable in Racket (in terms of
performance)?
That is a good question, and the answer is 'yes, in the right situation'. I
think the use in the
The simulation collection uses continuations extensively - in essence
it is a continuation engine - and I get very good performance from it,
even for very large simulations.
On Mon, Sep 17, 2012 at 4:24 PM, Matthias Felleisen
wrote:
>
> On Sep 16, 2012, at 2:36 PM, Patrick Useldinger wrote:
>
>>
On Sep 16, 2012, at 2:36 PM, Patrick Useldinger wrote:
> Which makes me wonder if continuations are really usable in Racket (in terms
> of performance)?
That is a good question, and the answer is 'yes, in the right situation'. I
think the use in the generator code might be not the right situa
On 16/09/2012 15:34, Neil Van Dyke wrote:
1. Use statistical profiler to see who is actually eating the time:
http://doc.racket-lang.org/profile/index.html Increasing the sampling
resolution can help.
This is what I get - only quoting the highest self pct:
Profiling results
-
Eli Barzilay wrote at 09/16/2012 11:15 AM:
If you need performance, your best bet is probably to translate things
to `for...' loops if possible.
In 5.3, can the "for"-something constructs ever result in faster code
than is possible with equivalent code using, say, named-"let"?
So far, it see
Two hours ago, Patrick Useldinger wrote:
> Hello
>
> I have a Python program doing some intensive computing and would
> like to port it to Racket for performance reasons.
>
> I use a generator in Python which has a very low overhead. While
> writing some test programs, I seem to have an substanti
Four things that might be helpful, in this case, and in general for
optimizing Racket code:
1. Use statistical profiler to see who is actually eating the time:
http://doc.racket-lang.org/profile/index.html Increasing the sampling
resolution can help.
2. Use DrRacket "Macro Stepper" to see e
23 matches
Mail list logo
