From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Extremely high overhead of 'par-map' Date: Fri, 29 Mar 2013 16:27:17 -0400 Message-ID: References: <1355559152.27310.5.camel@Renee-desktop.suse> <87y5d8rclr.fsf@gnu.org> <1364439334.2730.41.camel@Renee-desktop.suse> <874nfwazc3.fsf@tines.lan> <1364524610.2730.48.camel@Renee-desktop.suse> <87d2uiah6h.fsf@tines.lan> <878v56agp1.fsf_-_@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b2e3d08242e0b04d9161a0e X-Trace: ger.gmane.org 1364588869 26737 80.91.229.3 (29 Mar 2013 20:27:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Mar 2013 20:27:49 +0000 (UTC) Cc: Mark H Weaver , guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 29 21:28:16 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ULfuG-0001oC-1W for guile-devel@m.gmane.org; Fri, 29 Mar 2013 21:28:12 +0100 Original-Received: from localhost ([::1]:46917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULftr-0001uQ-Qs for guile-devel@m.gmane.org; Fri, 29 Mar 2013 16:27:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULftn-0001uK-Dl for guile-devel@gnu.org; Fri, 29 Mar 2013 16:27:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULftj-0004P2-2r for guile-devel@gnu.org; Fri, 29 Mar 2013 16:27:43 -0400 Original-Received: from mail-pa0-f42.google.com ([209.85.220.42]:52759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULfti-0004Ol-Oy for guile-devel@gnu.org; Fri, 29 Mar 2013 16:27:39 -0400 Original-Received: by mail-pa0-f42.google.com with SMTP id kq13so485102pab.1 for ; Fri, 29 Mar 2013 13:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=blPD91zk43vT3YLX9inRr04S6y573yZ7DeyHDMdJ7AY=; b=s3OHh7rE1sIhBtoFz7FNDrpfaFg0L/qi3eTdSiPldcnNemycqAMMEbimNZSEagsicf xeBRlUrDlSe53+bFjNQzo9xfmhzTqg8L+4gEe+YdyelOynLMq+cBSotXSWJoAwGK9GII 9difKZsEeG6bF41n4cwHTLdPLclLdichZYl82BFtFlDulxQsZT/nMzHbPpqZlF//Dzn8 Zi/x8sgSfIGrWscxYM/3dKNk0zCp9FkZB66GMAxCfm11bbfYY+ou/FYnlIvqM8CvpJ5+ 9Gmy2cHGr4A8txchLD24+G0WSMzo9TIQcbNVWmLAS+Fq7EiDuko43o9m8uwHyIFyZCpz OBjg== X-Received: by 10.68.247.163 with SMTP id yf3mr5576625pbc.113.1364588857927; Fri, 29 Mar 2013 13:27:37 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Fri, 29 Mar 2013 13:27:17 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: 3Qo4DKtnF8D-f8huMhEEx3GTh84 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.42 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16058 Archived-At: --047d7b2e3d08242e0b04d9161a0e Content-Type: text/plain; charset=ISO-8859-1 Oh, sorry to email twice so soon, but I have an idea for making par-map usable in more cases: add a keyword argument called "block-size". Its value should be a positive integer, and the meaning is to have each thread do block-size iterations. That should make it easier to use par-map for cases like this where the cost of each function is very small. I realize it's not a great solution because you still have to iterate through the list to get to the later elements. A hypothetical "vector-par-map" would solve that. Noah On Fri, Mar 29, 2013 at 4:24 PM, Noah Lavine wrote: > I agree. Do you have any idea what's causing the overhead? > > I tried to benchmark it, but got a segmentation fault. I think we have > plenty of work to do here. :-) > > Noah > > > On Fri, Mar 29, 2013 at 2:00 AM, Mark H Weaver wrote: > >> I wrote: >> >> > Nala Ginrut writes: >> >> --------------------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------------------- >> > [...] >> >> Well, is there any example? >> > >> > The timings above suggest that, on your machine, the overhead of >> > 'par-map' is in the neighborhood of 660 microseconds per thread (that's >> > the total run time divided by 10000 iterations). >> >> I must say that 'par-map' has shockingly poor performance. >> We really ought to try to improve this. >> >> Mark >> >> > --047d7b2e3d08242e0b04d9161a0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oh, sorry to email twice so soon, but I have an idea = for making par-map usable in more cases: add a keyword argument called &quo= t;block-size". Its value should be a positive integer, and the meaning= is to have each thread do block-size iterations. That should make it easie= r to use par-map for cases like this where the cost of each function is ver= y small.

I realize it's not a great solution because you still have to= iterate through the list to get to the later elements. A hypothetical &quo= t;vector-par-map" would solve that.

Noah


On Fri, Mar 29, 2013 at 4:24 PM, Noah La= vine <noah.b.lavine@gmail.com> wrote:
I agree. Do you have any idea what's causing the = overhead?

I tried to benchmark it, but got a segmentation faul= t. I think we have plenty of work to do here. :-)

Noah


On Fri, Mar 29, 2013 at 2:00 AM, Mark H = Weaver <mhw@netris.org> wrote:
nalaginrut@gmail.com> writes:
>> --------------------cut-------------------
>> scheme@(guile-user)> ,time (define a (map (lambda (x) (expt x 5= )) (iota
>> 10000)))
>> ;; 0.008019s real time, 0.007979s run time. =A00.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. =A01.513880s spent in = GC.
>> --------------------end-------------------
> [...]
>> Well, is there any example?
>
> The timings above suggest that, on your machine, the overhead of
> 'par-map' is in the neighborhood of 660 microseconds per threa= d (that's
> the total run time divided by 10000 iterations).

I must say that 'par-map' has shockingly poor performance.
We really ought to try to improve this.

=A0 =A0 =A0Mark



--047d7b2e3d08242e0b04d9161a0e--