Maybe the reason is the STM.
If I rmember it correctly, then agents and refs are controlled by
Clojures STM mechanic. Eventuelly the us of map increase the work for
the STM and so it needs more time to schedule all the agent calls and
this result in a higher memory usage.
When you use pmap the calls are working in parallel and the STM might
have less agents calls to schedule and this might reduce the stress.
On the otherside, the work the agents have do to is not so hard and the
STM might shine in comparison to pmap or other parallel calls if there
is much more work to do.
But these are only guesses...
Am 02.04.2012 23:13, schrieb Jim - FooBar();:
Ok i understand what you mean...i had a closer look at the code and it
seems that the hard work is done by agents...However, I did some
further testing out of curiosity and got back some weird
behaviour...On my machine it doesn't really matter whether i have 2 or
3 domiciles - i will still get the answer in less than a minute.
However it does matter whether i use pmap or map. For some reason i
don't understand, when i use 'map', CPU load never exceeds 60% but my
RAM goes to 71% (from 37% ) and as a result the terminal starts to lag
which is obviously not good! On the other hand when i use 'pmap' my
RAM only goes up by 1% and my CPU load skyrockets to 99%!!! That is
really amazing isn't it...I also get the answer a lot quicker
(roughly 20 sec with 2 domiciles)....Can somebody explain? I totally
agree with Marcus point that agents are asynchronous and so pmap
should only add overhead...It seems however that pmap does the
ccorrect job here...
Jim
p.s: Marcus run it for ourself using pmap and 2 domiciles and compare
it with previous runs...
I 've not changed the code at all apart from adding the missing space...
On 02/04/12 21:33, Marcus Lindner wrote:
I think the reason here is, that the used agents perform the
day-of-life function.
Another reason is also, that the individual, which is created by the
agent, is put again into teh ref population. Could be that this might
prefent the use of pmap, or increase the time for the scheduling.
When you look at the day-in-life function, you see that the
individual and its firtness score is put into the population ref by a
swap!.
And because you send the function to the agents, these functions are
resovled in a asynchron way and every agents performs the function
"parallel".
(Hope this makes sense, english is not my mother tongue :( .)
So the parallel processing is performed by using the x agents.
By the way, on my slow machine it works best with onyl 2 domiciles
(agents). On an other with 12 cores the domiclies can go up much
more, but I have not find out how much.
Am 02.04.2012 20:34, schrieb Jim - FooBar();:
Shouldn't the line (inside start-evolution) :
*(map #(send % a-day-in-the-life-agent-fn) domiciles)
*
be:
*(pmap #(send % a-day-in-the-life-agent-fn) domiciles)* ???
why does it need to happen serially?
Jim
On 02/04/12 19:06, Goldritter wrote:
First there is an error in my code :(
These are the allowed symbols from which the creator function can
choose to create or mutate a gen:
def allowed-symbols (str "abcdefghijklmnopqrstuvwxyzäöü"
"ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜ"))
This is the targetd which should be fulfilled:
(def the_target "Thursday Next")
The first error is, that in the allowed symbols the Space (' ') is
missing. So without this symbol/character the algorithm has no chance
to finish.
The correct definition for the symbols are (with the missing space):
def allowed-symbols (str "abcdefghijklmnopqrstuvwxyzäöü "
"ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜ "))
So the algorithm tries to design the String "Thursday Next" by
exploring many possible variations and to get as near as possible to
the solution "Thursday Next".
The main purpose of this algorithm, I think, is to show how you can
use agents and atoms to implement a genetic algorithm.
On Apr 2, 7:59 pm, "Jim - FooBar();"<jimpil1...@gmail.com> wrote:
Is it possible to explain briefly what this genetic algorithm tries to
accomplish? I mean what problem is it producing solution for? It never
seems to end regardless of number-of-domiciles!
I think i got a glimpse of a "ThursdayGNEXT" string but i'm not sure
what it means...
Jim
On 26/03/12 09:47, Marcus Lindner wrote:
Thanks for the answer.
Yes, the number of domicles was the problem.
When I use one or two domiciles the population remains relativ stable.
If I use 3 or more, then the population is increasing.
Is it a good idea to add some helpers for the grimreaper if the
population grows too fast?
Marcus
2012/3/26 Stefan Kamphausen<ska2...@googlemail.com
<mailto:ska2...@googlemail.com>>
Hi,
> For my little project I wanted to reprogramm the gentic
algorithm from
> the book "Clojure" written by Stefan Kamphausen and Tim Oliver
Kaiser.
quickly glancing at the code, it looks like a valid translation
into English.
Did you try to tune number-of-domiciles? Depending on your
machine it may be necessary to decrease the number of creators so
that the population doesn't grow. In this simulation the
grimreaper has a hard time working against the birth-rate. ;-)
Feel free to get in contact with me via e-mail[1] if your problem
persists.
Kind regards,
Stefan
[1] (apply str (reverse ["de" \. "clojure-buch" (str "ska@")]))
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email tocloj...@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email tocloj...@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
