Re: map-par slower than map

[Damien Mattei]

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

On Thu, Nov 10, 2022 at 6:07 PM Olivier Dion <olivier.dion@polymtl.ca>
wrote:

> On Thu, 10 Nov 2022, Damien Mattei <damien.mattei@gmail.com> 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
> oldiob.dev
>