unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Damien Mattei <damien.mattei@gmail.com>
Cc: guile-user <guile-user@gnu.org>, Olivier Dion <olivier.dion@polymtl.ca>
Subject: Re: map-par slower than map
Date: Fri, 11 Nov 2022 12:25:53 +0000	[thread overview]
Message-ID: <d00f1504-3fa5-56ba-ff13-1378a3100e31@posteo.de> (raw)
In-Reply-To: <CADEOadfHLJyfPiKyq6DPYCu7tpJogjnT3rcoM+oNfUYiRSf47Q@mail.gmail.com>

Hi!

On 11/11/22 11:26, Damien Mattei wrote:
> i rewrote a complete threaded routine both with guile and racket creating 
> threads and waiting they finish :
> ;; run the parallel code
>   {threads <+ (map (λ (seg) (call-with-new-thread
>     (λ () (proc-unify-minterms-seg seg))))
>   segmts)}
>
>   (nodebug
>    (display-nl "waiting for threads to finish..."))
>
>   ;; wait for threads to finish
>   (map (λ (thread) (join-thread thread)) ;;(+ start-time max-sleep)))
>        threads)
>
>  it does not seems to block but it is a bit slower than on a single CPU.
>
> i have this config:
> Puce : Apple M1
>   Nombre total de cœurs : 8 (4 performance et 4 efficacité)
> it is better on a single cpu than with all the cores...
>
> i read all the doc of Posix Thread, i admit Scheme is not C , i read on forums 
> a few about C and Scheme comparaison.
> In any thread local variables should be on the stack of each thread.
> The only doubt i have is in Scheme (but the same question exist in C) what 
> portions of code are or not copied in any thread? for this reason i tried to 
> encapsulate all the procedures used in // as internals defines in the 
> procedure passed at call-with-new-thread hoping they are copied in each 
> threads. I hope the basic scheme procedures are reentrant...
> I have no explaination why is it even a bit slower on multiple core than on one.
>
> Regards,
> Damien

Note, that threads in Guile and Racket are different:

https://docs.racket-lang.org/reference/eval-model.html#%28part._thread-model%29:

 > Racket supports multiple threads of evaluation. Threads run concurrently, in 
the sense that one thread can preempt another without its cooperation, but 
threads currently all run on the same processor (i.e., the same underlying 
operating system process and thread).

https://www.gnu.org/software/guile/manual/html_node/Threads.html:

 > The procedures below manipulate Guile threads, which are wrappers around the 
system’s POSIX threads. For application-level parallelism, using higher-level 
constructs, such as futures, is recommended (see Futures).

I believe another word for Racket's threads is "green threads". They are like 
(more like?) Python threads, and do not run on another core. If you start 
multiple Racket threads on the same Racket VM, they will run all on the same 
core. No speedup to be expected, unless you would be waiting for IO or 
something, if you did not use threads. Racket threads are concurrent, but not 
parallel.

I think Racket's threads' nature is the answer to why it is slower than single 
threaded execution.

Regards,
Zelphir

-- 
repositories:https://notabug.org/ZelphirKaltstahl


  reply	other threads:[~2022-11-11 12:25 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 17:19 map-par slower than map Damien Mattei
2022-10-12 18:45 ` Maxime Devos
2022-10-12 20:20   ` Damien Mattei
2022-10-12 20:27     ` Damien Mattei
2022-10-12 21:29       ` Zelphir Kaltstahl
2022-10-14  8:21         ` Damien Mattei
2022-10-14  8:38           ` Zelphir Kaltstahl
2022-10-17 13:17             ` Damien Mattei
2022-10-22 16:01               ` Damien Mattei
2022-10-23  1:06                 ` Damien Mattei
2022-10-23 23:18                   ` Zelphir Kaltstahl
2022-10-24  3:56                     ` Keith Wright
2022-10-24  7:03                       ` Zelphir Kaltstahl
2022-10-24  4:39                     ` Damien Mattei
2022-10-25  9:07         ` Mikael Djurfeldt
2022-10-25  9:11           ` Mikael Djurfeldt
2022-10-25 14:09             ` Damien Mattei
2022-11-10 10:32         ` Damien Mattei
2022-11-10 10:41           ` Damien Mattei
2022-11-10 10:52             ` Zelphir Kaltstahl
2022-11-10 13:36               ` Damien Mattei
2022-11-10 17:07           ` Olivier Dion via General Guile related discussions
2022-11-11 10:26             ` Damien Mattei
2022-11-11 12:25               ` Zelphir Kaltstahl [this message]
2022-11-11 13:36                 ` Damien Mattei
2022-11-11 13:37                   ` Damien Mattei
2022-11-13  8:23                     ` Damien Mattei
2022-10-12 21:44     ` Maxime Devos
2022-10-12 21:55 ` Olivier Dion via Developers list for Guile, the GNU extensibility library
2022-10-13  7:40   ` Damien Mattei
2022-10-13  8:20     ` Damien Mattei
2022-10-13  9:10     ` Olivier Dion via Developers list for Guile, the GNU extensibility library
2022-10-13 10:44   ` Damien Mattei
2022-10-13 11:00     ` Olivier Dion via Developers list for Guile, the GNU extensibility library
     [not found]       ` <CADEOadfovi8s3OxRcssWOuOW8jjHoL9Z7pD_5FstSm=ZkBHP8g@mail.gmail.com>
2022-10-13 11:57         ` Fwd: " Damien Mattei
2022-10-13 12:36           ` Damien Mattei
2022-10-13 12:41             ` Olivier Dion via Developers list for Guile, the GNU extensibility library
2022-10-13 13:43               ` Damien Mattei
2022-10-13 14:06                 ` Olivier Dion via Developers list for Guile, the GNU extensibility library
2022-10-13 14:10                   ` Damien Mattei
2022-10-13 14:21                     ` Damien Mattei

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=d00f1504-3fa5-56ba-ff13-1378a3100e31@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=damien.mattei@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=olivier.dion@polymtl.ca \
    /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).