Re: map-par slower than map

[Damien Mattei]

it just an idea, but i explore the way to fork() my code,use some shared
memory (for the minterms vector) to get more system ressource (CPUs), i did
not find the equivalent to fork() under unix in Guile or an API to manage
shared memory (like in unix) but i read that C and guile can be used
together:
https://www.gnu.org/software/guile/manual/html_node/Combining-with-C.html
but i can not find any example, is there a place i can find more
documentation and tutorials about that ?

Best Regards,
Damien

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

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