unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Nala Ginrut <nalaginrut@gmail.com>
Cc: guile-devel@gnu.org
Subject: Re: Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow)
Date: Fri, 29 Mar 2013 01:49:58 -0400	[thread overview]
Message-ID: <87d2uiah6h.fsf@tines.lan> (raw)
In-Reply-To: <1364524610.2730.48.camel@Renee-desktop.suse> (Nala Ginrut's message of "Fri, 29 Mar 2013 10:36:50 +0800")

Nala Ginrut <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.  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).  So if the procedure
takes significantly longer than that to run, the overhead will not be so
bad.  For example, if the procedure takes 10 milliseconds to run, then
the 'par-map' overhead would be about 6.6% (660/10000).  If the
procedure takes 100 milliseconds to run, then the overhead would be
about 0.6% (660/100000).

That's the way I'd suggest to think about it.

     Mark



  reply	other threads:[~2013-03-29  5:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1355559152.27310.5.camel@Renee-desktop.suse>
     [not found] ` <87y5d8rclr.fsf@gnu.org>
2013-03-28  2:55   ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Nala Ginrut
2013-03-28  5:05     ` Mark H Weaver
2013-03-28 13:44       ` Ludovic Courtès
2013-03-28 18:00         ` Mark H Weaver
2013-03-28 20:07           ` Ludovic Courtès
2013-03-29  2:36       ` Nala Ginrut
2013-03-29  5:49         ` Mark H Weaver [this message]
2013-03-29  6:00           ` Extremely high overhead of 'par-map' Mark H Weaver
2013-03-29 20:24             ` Noah Lavine
2013-03-29 20:27               ` Noah Lavine
2013-03-29 23:18                 ` Mark H Weaver
2013-03-30 23:37             ` Ludovic Courtès
2013-03-29 16:45           ` Whats' the proper senario of par-map? (Was Re: bug#13188: par-map causes VM stack overflow) Mark H Weaver
2013-04-01 19:10           ` Andy Wingo
2013-03-29  9:52         ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2uiah6h.fsf@tines.lan \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=nalaginrut@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).