GNU bug report logs - #13188
par-map causes VM stack overflow

Previous Next

Full log

Message #16 received at 13188-done <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Nala Ginrut <nalaginrut <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 13188-done <at> debbugs.gnu.org,
	guile-devel <at> gnu.org
Subject: Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map
	causes VM stack overflow)
Date: Thu, 28 Mar 2013 01:05:32 -0400

Nala Ginrut <nalaginrut <at> gmail.com> writes:

> But I'm still puzzled with the performance of par-map:
> --------------------cut-------------------
> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5)) (iota
> 10000)))
> ;; 0.008019s real time, 0.007979s run time.  0.000000s spent in GC.
> scheme@(guile-user)> ,time (define a (par-map (lambda (x) (expt x 5))
> (iota 10000)))
> ;; 6.596471s real time, 6.579375s run time.  1.513880s spent in GC.
> --------------------end-------------------
>
> So my question is, what's the proper scenario to use par-map?

It only makes sense to use 'par-map' when the procedure is fairly
expensive to compute.  There is inevitably a lot of overhead in creating
and joining the threads.  Granted, we should be able to do much better
than we're doing now, but it would *never* make sense to use 'par-map'
when each computation is as simple as (expt x 5).

      Regards,
        Mark

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.