Re: map-par slower than map

[Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>]

Hello Keith!

On 10/24/22 05:56, Keith Wright wrote:
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>
>> 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.
> Indeed.
>
>> I do not think that futures are to blame here,
>> or parallel map in that case.
> Are futures to blame?  Do you blame the plus sign for
> this wrong equation:  4+5=20?
> My teachers blamed me for that sort of thing.

I do not know your teachers, but in my experience futures work well in Guile : )

Blaming a construct like futures for the results of using shared global state 
seems really unreasonable.

>> With a synchronization construct, some kind of mutex,
>> your bottle neck might just become that mutex.
> But why make it parallel at all?  Unless you have some serious
> parallel hardware you will just be wasting time in the scheduler
> when you could be computing the answer.

Assuming, that parallelization is possible and a problem is not inherently of 
sequential nature, of course there is hope for a speedup to be achieved. When 
parallelizing properly (which might involve finding a different algorithm) there 
might not be any resource conflict between the futures or OS threads running, so 
time will not be "time wasted in the scheduler".

According to what Damien has written the parallelization has already sped up his 
calculations a lot. I think it is fair to assume, that it is at least partly 
working : )

I agree though, that pages of boolean expressions are not really that 
interesting to have in the mailbox ; )

Regards,
Zelphir

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