Well I've got some results!!!
Firstly and more importantly, it was a great idea to put all the logical
moves of the pieces on a table (2 level nested map). There is absolutely
no need to recalculate them every time! nice catch Nicolas... the
profiler now shows some 9000 less objects and sampling the memory shows
byte[][] and char[] dominating (instead of core.logic.Substitutions and
clojure.lang.RT.nth)...this should have been done from day 1!
As you suggested I defined an atom in order to check how many boards are
being generated by the real 'generate' fn. Here are the results (using
(rand-int 10) to score the leaves):
level 2:
--dummy: 27,000 leaves (0.5 sec)
--real: 8,000 leaves (19 sec)
level 3:
--dummy: 810,000 leaves (8 sec) (30 times more)
--real: 160,000 leaves (327 sec) (100 times more)
This tells us 2 things...
1) generating real boards is going to be at least 20 times more
expensive than just repeating the same one!
2) using real generation of boards, we can see that level 3 has 20 times
more leaves than level 2, which is NOT intuitive at first glance! level
3 should have just over 20 times more leaves because some nodes will
have 21 children...careful debugging however shows that this is
compensated by some nodes having 19 children...at least for such small
depth this is what seems to be happening...the 'next-level' fn has been
thoroughly tested and does return the correct successors so I don't know
what else to think...
performance is a bit horrible even though the fn that does the
difference (next-level) is only called 2, 3 or 4 times (one for each
level)...calling it on its own, on a real board full with pieces,
returns in less than 35 ms while the dummy equivalent (repeat ... ... )
returns instantly (less than 1ms). But both these fns should only be
called n times (where n is the depth)...this is weird stuff indeed...
Jim
On 23/08/12 12:43, Jim - FooBar(); wrote:
On 23/08/12 09:35, nicolas.o...@gmail.com wrote:
If it is so slow, that's maybe because the branching factor is very
high.
Could you have an atom incremented in your evaluation function, or in
next level, to check how many boards are generated for level 2 or 3?
(At least this could give an approximate time for computing each board.
(83 - 8) / num board computed. To check it is in line with what you
mesured of core.logic.)
hmm...good idea! I'll try that....
And why do you need an atom in the move function?
(When is it changed?)
Apart from the 'try-move' fn that is part of the Move protocol I also
have an 'execute!' fn that simply calls 'try-move' and resets the
board atom with the result of 'try-move' (a new board). This is not
called at all in searching - only when I've got my gui up and actually
playing on screen...
Lastly, if you just need core.logic to compute valid moves from the
logical rules of chess and do not check they actually
apply here, you could precompute that into a big table, which might or
not be faster.
hmmm i'd never thought of that! I would need a table with roughly 64
rows (the board) x 6 columns (the pieces)...I will try that as well!
thanks Nicolas
Jim
--
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
