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
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
wrote:
> Hi Zelphir,
>
>
> On Fri, Nov 11, 2022 at 1:25 PM Zelphir Kaltstahl <
>
Hi Zelphir,
On Fri, Nov 11, 2022 at 1:25 PM Zelphir Kaltstahl <
zelphirkaltst...@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
Hi!
On 11/11/22 11:26, Damien Mattei wrote:
i rewrote a complete threaded routine both with guile and racket creating
threads and waiting they finish :
;; run the parallel code
{threads <+ (map (λ (seg) (call-with-new-thread
(λ () (proc-unify-minterms-seg seg
segmts)}
(nodebug
i rewrote a complete threaded routine both with guile and racket creating
threads and waiting they finish :
;; run the parallel code
{threads <+ (map (λ (seg) (call-with-new-thread
(λ () (proc-unify-minterms-seg seg
segmts)}
(nodebug
(display-nl "waiting for threads to
On Thu, 10 Nov 2022, Damien Mattei wrote:
> Hello Zelphir,
>
> i finally find a possible cause of no speed up of my code, i find that
> using your code the procedure keep blocked on the first 'touch at line 27
> here:
>
I have found a possible deadlock with Guile's mutex. In some very rare
as it worked with your code it is incompatibility between my procedures and
'future.
I read 'future require pure function,ok my function are not pure but the
side effect they did are on partitioned sets of data, so there is no reason
for concurrence accessing data between each threads.
I will try
Hi Damien!
I think Racket futures and Guile futures are a bit different. According to the
Racket documentation "The level of parallelism available from those constructs,
however, is limited by several factors, and the current implementation is best
suited to numerical tasks."
note that it is not a Guile problem, the same code give also no speed up
with Racket 'future ,i have not already test it but it should block also on
'touch future...
On Thu, Nov 10, 2022 at 11:32 AM Damien Mattei
wrote:
> Hello Zelphir,
>
> i finally find a possible cause of no speed up of my
Hello Zelphir,
i finally find a possible cause of no speed up of my code, i find that
using your code the procedure keep blocked on the first 'touch at line 27
here:
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
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:
>
>
Hello Keith!
On 10/24/22 05:56, Keith Wright wrote:
Zelphir Kaltstahl 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
Hello Zelphir,
i should had written first about the mathematical problem first but i did
not want to go into other than computer things. But i expose here the main
idea briefly: i try to solve a mathematical conjecture (
https://en.wikipedia.org/wiki/Conjecture ) using logic expressions but not
in
Zelphir Kaltstahl 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
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
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
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
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
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
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
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
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
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
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
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
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
sorry google always do reply to single 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 good if your
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
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
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:
the 'map-par slower than map') and
to change it to standard-ish Scheme instead of your Scheme+ variant.
On Wed, Oct 12, 2022 at 8:45 PM Maxime Devos <mailto:maximede...@telenet.be>> wrote:
[rest of copied previous message, without any comments]
This is top-posting. For why not to
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
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
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
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!?
what i change in code is in comments:
{unified-minterms-set-1 <+ (map function-unify-minterms-list minterms-set)}
;;(par-map
41 matches
Mail list logo
