[plt-scheme] Futures performance

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Fri May 28 07:38:25 EDT 2010

Which edit?

Jon's suggestion of making fibp recursively call itself intead of
calling fib would certainly kill the parallelism. The original program
seems to be as it should have been to effectively use our futures (on
two cores).

Robby

On Fri, May 28, 2010 at 6:35 AM, Shriram Krishnamurthi <sk at cs.brown.edu> wrote:
> Robby, once we make the edit, both Jon and I see results very similar
> to the original report.
>
> Shriram
>
> On Thu, May 27, 2010 at 11:53 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> Since we are having trouble reproducing the behavior you are seeing,
>> perhaps you can supply us with more information? What version are you
>> running? Are you running inside drscheme or not?
>>
>> Also note that if you pass the flags
>>
>>  -W debug
>>
>> to mzscheme you can see if your future threads are blocking.
>>
>> Robby
>>
>> 2010/5/27 Groshev Dmitry <a2alt at yandex.ru>:
>>>> On Wed, May 26, 2010 at 11:44 PM, Jon Rafkind  wrote:
>>>>  > On 05/25/2010 08:53 PM, Groshev Dmitry wrote:
>>>>  >>
>>>>  >> What am I doing wrong? Here is the code and some tests:
>>>>  >>
>>>>  >> (require scheme/future)
>>>>  >>
>>>>  >> (define (fib n)
>>>>  >>   (case n
>>>>  >>     [(0) 0]
>>>>  >>     [(1) 1]
>>>>  >>     [else (let ((a (fib (- n 1)))
>>>>  >>                 (b (fib (- n 2))))
>>>>  >>             (+ a b))]))
>>>>  >>
>>>>  >> (define (fibp n)
>>>>  >>   (case n
>>>>  >>     [(0) 0]
>>>>  >>     [(1) 1]
>>>>  >>     [else (let ((a (future (lambda () (fib (- n 1)))))
>>>>  >>                 (b (future (lambda () (fib (- n 2))))))
>>>>  >>             (+ (touch a) (touch b)))]))
>>>>  >>
>>>>  >>
>>>>  >>>
>>>>  >>> (time (fib 30))
>>>>  >>>
>>>>  >>
>>>>  >> cpu time: 546 real time: 539 gc time: 0
>>>>  >> 832040
>>>>  >>
>>>>  >>>
>>>>  >>> (time (fibp 30))
>>>>  >>>
>>>>  >>
>>>>  >> cpu time: 8986 real time: 7814 gc time: 391
>>>>  >> 832040
>>>>  >>
>>>>  >
>>>>  > Is that actually the code you are running? If I take your code verbatim I
>>>>  > get times like these
>>>>  >
>>>>  > ;; I set n to 40 so you can see a real difference
>>>>  > cpu time: 6100 real time: 6448 gc time: 0
>>>>  > 102334155
>>>>  > cpu time: 6132 real time: 3995 gc time: 0
>>>>  > 102334155
>>>>  >
>>>>  >
>>>>  > But if I change the code so that `fibp' makes recursive calls to `fibp'
>>>>  > instead of `fib' then I see `fibp' taking much longer.
>>>>  > ;; n = 33
>>>>  > cpu time: 496 real time: 498 gc time: 0
>>>>  > 3524578
>>>>  > cpu time: 17429 real time: 18720 gc time: 748
>>>>  > 3524578
>>>>  >
>>>>
>>>>  Last I heard, you can't create futures within a future (the runtime
>>>>  blocks the future that tried).
>>>>
>>>>  If that's still the case, it explains why you see no speedup. I don't
>>>>  know if that's enough to cause the slowdown you're seeing.
>>>>
>>>>  > Which is similar to your results. What sort of machine are you on? I'm on a
>>>>  > dual-core amd 1.8ghz laptop.
>>>>  > _________________________________________________
>>>>  >  For list-related administrative tasks:
>>>>  >  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>>  >
>>>>  >
>>>>  _________________________________________________
>>>>    For list-related administrative tasks:
>>>>    http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>>
>>> Yes, it must be "fibp", not "fib".
>>> Runtime blocking is an explanation, but it seems to me that there is still to much slowdown for just blocking.
>>> _________________________________________________
>>>  For list-related administrative tasks:
>>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>


Posted on the users mailing list.