[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: map-par slower than map

From: Damien Mattei
Subject: Re: map-par slower than map
Date: Fri, 11 Nov 2022 11:26:17 +0100

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))))

   (display-nl "waiting for threads to finish..."))

  ;; wait for threads to finish
  (map (λ (thread) (join-thread thread)) ;;(+ start-time max-sleep)))

 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


On Thu, Nov 10, 2022 at 6:07 PM Olivier Dion <>

> On Thu, 10 Nov 2022, Damien Mattei <> wrote:
> > Hello Zelphir,
> >
> > i finally find a possible cause of no speed up of my code, i find that
> > using your code the procedure keep blocked on the first 'touch at line 27
> > here:
> >
> I have found a possible deadlock with Guile's mutex.  In some very rare
> cases, ice-9 futures deadlock because of it.
> Maybe it's not the case here I haven't read the code you've mentioned.
> Just letting you know.
> --
> Olivier Dion

reply via email to

[Prev in Thread] Current Thread [Next in Thread]