Hello Mikael,
your message comes very well because i decided yesterday,partly due to the
discussion in mailing list, to review all the // method used in my code and
to use them to perform benchmark to see which one is preferable to use with
the algorithmic problem of putting a logic expression in
A piece of background on par-map:
When I introduced par-map et al the only ambition was to have simple
language constructs to invoke parallelism. The use case I had in mind was
course grained parallelism where each piece of work is somewhat
substantial. Back then, a thread was launched for each pi
Also, I would believe that any crashes in this context are neither due to
the futures implementation nor par-map et al. I would think that crashes
are due to the Guile basic thread support itself.
On Tue, Oct 25, 2022 at 11:07 AM Mikael Djurfeldt
wrote:
> A piece of background on par-map:
>
> Wh
just for the fun things, i just find that the parallelized results are
false :-) even for low indices:
the non // result: C5 = ((B1 ∧ B3) ∨ (B2 ∧ B3) ∨ (B2 ∧ B4))
is different than the parallelized result below:
C5 = ((B1 ∧ B3) ∨ (B2 ∧ B3) ∨ (B2 ∧ B4) ∨ (B3 ∧ B4))
i have to check things again ,i t
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 e
Hello,
sorry for my late answer ( i wrote the code friday but i could only debug
today, being busy and on travel last week-end)
i modified my code to works with 'futures' , the speed is now incredible
!!! (and it computes exact)
the speed seems multiplied by even more than the number of CPUs (6):
yes Zelphir i think there is a problem in the threading part of guile,
whatever the code is ,it run well the first time, and after is unstable.
Long ago at the very begin of Java language on my master project at
university i experienced same problem with Java "green" threads, under
windows and/or l
Hello Damien,
On 10/14/22 10:21, Damien Mattei wrote:
yes Zelphir i think there is a problem in the threading part of guile,
whatever the code is ,it run well the first time, and after is unstable. Long
ago at the very begin of Java language on my master project at university i
experienced sam
ok i have the proof, this time (second time) the process stopped itself on
your example ("processus stoppé " in french) :
mattei@pc-mattei:~/Dropbox/git/library-FunctProg$ guile
GNU Guile 3.0.1
Copyright (C) 1995-2020 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for det
On Thu, Oct 13, 2022 at 4:06 PM Olivier Dion
wrote:
> On Thu, 13 Oct 2022, Damien Mattei wrote:
> > i do not see what has changed in your code ?
>
> Just copy it. Trust me it has changed.
>
really ? :-) i read it 3 times line by line, yes the end is cut ,still no
ending ) and i use it and freez
On Thu, 13 Oct 2022, Damien Mattei wrote:
> i do not see what has changed in your code ?
Just copy it. Trust me it has changed.
> really strange,even with bad code the moment it crash should be the same,
> sometimes works,crash or freeze
I don't get any of these problem .. running with (io
i do not see what has changed in your code ?
really strange,even with bad code the moment it crash should be the same,
sometimes works,crash or freeze
On Thu, Oct 13, 2022 at 2:41 PM Olivier Dion
wrote:
> On Thu, 13 Oct 2022, Damien Mattei wrote:
> > the code did not worked when data length
On Thu, 13 Oct 2022, Damien Mattei wrote:
> the code did not worked when data length were more little than number of
> cpus (6 on my host) (iota 5) returns #unsepcified:
Yeah sorry I miss indended the output and the rest. Here's a version
that should work:
--8<---cut here
gle author...
>
> -- Forwarded message -
> From: Damien Mattei
> Date: Thu, Oct 13, 2022 at 1:56 PM
> Subject: Re: map-par slower than map
> To: Olivier Dion
>
>
> ah just at the end? i had noticed, but i get #unspecifeid ? so my new code
> is not go
On Thu, 13 Oct 2022, Damien Mattei wrote:
> i trying to use your code but it seems there is a ) mismatch
> somewhere?
Right there's a missing ')' a the end to close the procedure, sorry
about that.
--
Olivier Dion
oldiob.dev
i trying to use your code but it seems there is a ) mismatch somewhere?
On Wed, Oct 12, 2022 at 11:55 PM Olivier Dion
wrote:
> On Wed, 12 Oct 2022, Damien Mattei wrote:
> > Hello,
> > all is in the title, i test on a approximately 3 element list , i got
> > 9s with map and 3min 30s with par
On Thu, 13 Oct 2022, Damien Mattei 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
ok 'parallelization code and hash table' in google show no real solution, i
have another idea,instead of function-unify-two-minterms-and-tag ,just
unify the minterms and tag them (which use hash table) later out of the //
region, after if it still sucks i will drop list for vectors, making it
step
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
On Wed, 12 Oct 2022, Damien Mattei wrote:
> Hello,
> all is in the title, i test on a approximately 3 element list , i got
> 9s with map and 3min 30s with par-map on exactly the same piece of
> code!?
I can only speculate here. But trying with a very simple example here:
--8<---c
On 12-10-2022 22:20, Damien Mattei wrote:
Mutex? i do not think code has situation where dead lock could happen,
it is a code about minimalising logic expressions, it uses minterms ,
minterms set is a set of minterms :like this:
I didn't mean deadlocks, I just meant a single mutex being take
Hi!
On 10/12/22 22:27, Damien Mattei wrote:
https://github.com/damien-mattei/library-FunctProg/blob/master/guile/logiki%2B.scm#L1674
i commited the current version of code here with all files but it is
huge :-/
On Wed, Oct 12, 2022 at 10:20 PM Damien Mattei
wrote:
Mutex? i do not think
https://github.com/damien-mattei/library-FunctProg/blob/master/guile/logiki%2B.scm#L1674
i commited the current version of code here with all files but it is
huge :-/
On Wed, Oct 12, 2022 at 10:20 PM Damien Mattei
wrote:
> Mutex? i do not think code has situation where dead lock could happe
Mutex? i do not think code has situation where dead lock could happen, it
is a code about minimalising logic expressions, it uses minterms , minterms
set is a set of minterms :like this:
example:
((1 1 0) (1 1 1)) will be unified : (1 1 x)
because 0 and 1 are replaced by x
the minterms-set could h
On 12-10-2022 19:19, Damien Mattei wrote:
Hello,
all is in the title, i test on a approximately 3 element list , i got
9s with map and 3min 30s with par-map on exactly the same piece of code!?
> [...]
>
translated from Scheme+ to Scheme:
(define unified-minterms-set-1 (map function-unify-m
25 matches
Mail list logo
