Hi all,
this post explains what is new on the trunk. My intention was to implement a
customisable test ordering based on the -asw weighting function. So you can do
something like:
--method random-dfs -to '[013467]=asw(1,0,0,2,0,0)'
Or:
--method random-dfs -to 0123467 -dto "16,0[123467]=asw(1,0,0,0,0,0)" \
-step 500 -sp r:tf --st-name 24 -nst
And the derived states will be sorted based on the result of the asw(...).
So I set up to implement it in multiple small steps starting from commit
50987fba5b40eedd60e95ac860153246f910ef47 :
https://bitbucket.org/shlomif/fc-solve/changeset/50987fba5b40eedd60e95ac860153246f910ef47
The first thing I did was add a 6th -asw weight for the count of irreversible
moves left. This was later converted to the number of cards not above their
parents (because the other part was already given by the 1st weight):
http://tech.groups.yahoo.com/group/fc-solve-discuss/message/1230
Then I went on the long road of making it possible to order groups based on
the previously-BeFS-only weighting function. This was eventually achieved
yesterday, with many separate commits, cleanups and refactorings along the way.
Then came the time to benchmark it and although it yielded a smaller number of
iterations, it was quite slower than the previous mostly-random-dfs based
scans (where I used a random function). I decided to investigate and to try to
improve.
So I turned to GPerftools and used their CPU profiler to profile the code:
http://code.google.com/p/gperftools/ , and discovered that most of the newly
added time was spent in befs_rate_state . After a series of optimisations
(mostly small, but there were at least two large ones), I was able to improve
its performance. Then I created an "=asw(…)" preset based on the most
performant preset todate - three-eighty, which was titled done with the working
name of "all-star", and ended up with this:
https://bitbucket.org/shlomif/fc-solve/src/d0b7040d265fac74315ed15a25813bb9a8badee5/fc-solve/source/Presets/testing-presets/all-star-4.sh?at=master
( short URL :
http://bit.ly/ScoIrT ).
Early versions of this scan quickly went below the 11 seconds mark (on my Core
i3 machine) and ran at 10.63454413414 seconds. Later version ran below 10
seconds, 9.92817306518555 seconds to be exact. This was improved somewhat after
compiling with profile-guided-optimisations: 9.73104000091553s .
So I'm very happy. I still need to document this feature properly in the
USAGE.txt document and also to release it as part of a stable release (which
will involve going over the logs and summarising the important stuff in
NEWS.txt.
Regards,
Shlomi Fish
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Rethinking CPAN - http://shlom.in/rethinking-cpan
C++ supports Object‐Oriented Programming roughly as much as COBOL supports
Functional Programming.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Received on Tue Oct 30 2012 - 02:33:07 IST