[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: srfi-45@xxxxxxxxxxxxxxxxx*Subject*: Re: simpler srfi 45 implementation*From*: "Phil Bewig" <pbewig@xxxxxxxxx>*Date*: Wed, 14 Nov 2007 08:29:31 +0100*Delivered-to*: srfi-45@xxxxxxxxxxxxxxxxx*In-reply-to*: <da4fbdb30711130759s105bba4ex5b9517767493297f@xxxxxxxxxxxxxx>*References*: <001001c825de$11b10380$2101a8c0@jos> <18233.39965.878836.78458@xxxxxxxxxxxxxxxxxxxxxx> <Pine.SOC.4.64.0711131036160.13665@xxxxxxxxxxxxxxxxx> <da4fbdb30711130759s105bba4ex5b9517767493297f@xxxxxxxxxxxxxx>*User-agent*: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.5-b28 (darwin)

Sorry, I hit 'Reply' instead of 'Reply to all'.

On Nov 13, 2007 9:59 AM, Phil Bewig <pbewig@xxxxxxxxx> wrote:

I did perform the SRFI-45 tests, and I think I did them on this version of the code, but I will confess I've been through enough versions of this recently that I'm not entirely sure I tested all of them.

I think at the moment I'll regress to the original SRFI-45 code for SRFI-41. If we all agree on a better version later I can always make the change.On Nov 13, 2007 9:54 AM, AndrevanTonder <andre@xxxxxxxxxxxxx> wrote:On Tue, 13 Nov 2007, Eli Barzilay wrote:The suggested optimization looks very suspicious also to me.

> I was aware of the possible optimization at the time, but didn't find

> any example where it mattered. However, if you do put it in:

>

>> [(promise? p)

>> (let* ((v (force p)))

>> (if (not (pair? (promise-p prom)))

>> (set-promise-p! prom (list v)))

>> (car (promise-p prom)))]

>

> then you do the recursive forcing of `p' in a non-tail conext. My

> (vague, not formal at all) feeling about these "referral promises" is

> that they do happen in places where the original code had a tail call,

> so it might be a bad idea to break it.

It seems that the non-tail-call could break space-safety.

Two questions:

- Have you run the SRFI-45 tests on your suggested optimization?

Note that this involves uncommenting the mostly nonterminating

test cases, letting them run for some time, keeping track

of the memory consumption with some other tool, and verifying

that it stays bounded. Of course, this is not a substitute

for a theoretical analysis, but it should show pretty quickly

if you are not on the right track.

- Did you find the same slowdown for the first implementation

given in the message

http://srfi.schemers.org/srfi-45/post-mail-archive/msg00010.html ?

(That one is easier for me to understand and comment on - Eli's

I would have to study again).

Cheers

Andre

**References**:**Re: simpler srfi 45 implementation***From:*Eli Barzilay

**Re: simpler srfi 45 implementation***From:*AndrevanTonder

- Prev by Date:
**Re: simpler srfi 45 implementation** - Next by Date:
**Re: simpler srfi 45 implementation** - Previous by thread:
**Re: simpler srfi 45 implementation** - Next by thread:
**Re: simpler srfi 45 implementation** - Index(es):