Re: map-par slower than map

[Zelphir Kaltstahl]

Hello Damien!

On 10/23/22 03:06, Damien Mattei wrote:
> after intense coding i finally got the good results,
> my assumption about the global variable hash table was true ,it is 
> incompatible with 'future : the competition for the writing into the hash 
> table breaks the code.
>
> If i do writing in hash table out of // region all is ok:
>
> a simple function to extract the hash table access:
>
> (define (tag-minterms i umt)
>   (when umt
>      {mt1 <+ (first {minterms-vector[i]})}
>      {mt2 <+ (second {minterms-vector[i]})}
>      {minterms-ht[mt1] <- #t}
>      {minterms-ht[mt2] <- #t}))
> [...]

I am not sure what exactly the problem is, which you are trying to calculate, 
but it looks fairly mathematical to me. Maybe you do not need to share state 
globally at all? Maybe you can find a way to avoid global shared state? I am 
guessing, that you want to avoid duplicated computation of part terms?

Of course,if you have global state and do not have a synchronization construct 
(!) for accessing the hash table, I would expect things to go wrong at some 
point, with non-reproducible results. I do not think that futures are to blame 
here, or parallel map in that case.

With a synchronization construct, some kind of mutex, your bottle neck might 
just become that mutex. Up to you to measure that ; )

Would be nice, if you found a clever way to separate the problems into disjunct 
parts and then solve them without global state.

Regards,
Zelphir

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