On Thu, 13 Oct 2022, Damien Mattei <damien.mat...@gmail.com> wrote: > ok , i think the problem comes both from my code and from guile parmap so. > Obviously parmap could be slower on other codes because of the nature of > list i think, it is hard to split a list in sublist and send them to thread > and after redo a single list, i better use vector. > As mentioned and forget by me, i apologize, i use an hash table which is a > global variable and mutex can be set on it , no dead lock , here but it > slow down the code than it is dead for speed , but not locked.
Your code is not the issue. The fact that `(par-map 1+ (iota 10000000))` is slow is the proof of that. I think that you should use par-map when you want to do I/O/subprocesses in parallel. Fast computation on a huge number of items should be done with vector because of its random access nature. List are simply no the good data structure for parallelization. > The examples given are good but i do not want to write long and specific > code for //, for // must a ssimple as OpenMP directives (on arrays) not be > a pain in the ass like things i already did at work with GPUs in C or > Fortran,that's nightmare and i do not want to have this in functional > programming. You're free to use my example of `par-map-vector` and tweak it to your needs. But maybe it's time for a `guile-parallel` for fast high level parallel. If others are interested in that, I can make one. -- Olivier Dion oldiob.dev