guile-user
[Top][All Lists]
Advanced

[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 14:37:48 +0100

in the previous mail ,read:
It seems again that only with this code Guile Racket can make another
thread only when the previous is finished (after touch)...

On Fri, Nov 11, 2022 at 2:36 PM Damien Mattei <damien.mattei@gmail.com>
wrote:

> Hi Zelphir,
>
>
> On Fri, Nov 11, 2022 at 1:25 PM Zelphir Kaltstahl <
> zelphirkaltstahl@posteo.de> wrote:
>
>>
>> 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).
>>
>
> oh! that is the reason with Racket of no speed up.
>
> 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).
>>
> yes but futures  seems to block on touch with guile, the same code under
> Racket,do not show speed up, it display a different output:
> run-in-parallel : making future
> run-in-parallel : touching future
> run-in-parallel : making future
> run-in-parallel : touching future
> run-in-parallel : making future
> run-in-parallel : touching future
> run-in-parallel : making future
> run-in-parallel : touching future
> run-in-parallel : making future
> run-in-parallel : touching future
> run-in-parallel : making future
> run-in-parallel : touching future
> it is different from the guile ouput.
> It seems again that only with this code Guile can make another thread when
> the previous is finished (after touch)...
>
> The code is this one:
>
> https://github.com/damien-mattei/library-FunctProg/blob/master/racket/logiki%2B.rkt#L3012
>
>
> https://github.com/damien-mattei/library-FunctProg/blob/master/racket/logiki%2B.rkt#L3331
>
> i do not think it could work faster if i cannot access to others CPUs like
> in OpenMP
> or this:
> https://en.wikipedia.org/wiki/Processor_affinity
> but it is not existing with Scheme.
>
> Best Regards,
> Damien
>
>> 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 via email to

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