Message6484

Author jendrik
Recipients jendrik, malte
Date 2017-09-01.13:59:46
Content
Let's try number 2.

I compared the "before" and "after" logs for systematic(2) on a woodworking task and it seems that all of the additional runtime 
comes from dominance pruning. Dominance pruning hashes pointer pairs. To analyze our old and new hashing algorithm for hashing 
pointer pairs, I created a new microbenchmark (with the new hash.h file). Here are the results (of the second benchmark run):


[...]/experiments/issue731/hash-microbenchmark$ export DOWNWARD_BITWIDTH=32 && make && ./benchmark${DOWNWARD_BITWIDTH}

Running nothing 100000 times: 0.000215s

Running insert pair<void *, void *> with BoostHash 100000 times: 0.9221s
Running insert pair<void *, void *> with BurtleFeed 100000 times: 0.996635s

Running count pair<void *, void *> with BoostHash 100000 times: 0.232802s
Running count pair<void *, void *> with BurtleFeed 100000 times: 0.341353s


These numbers don't explain the change in runtime we're seeing. I'm not sure if my approach to generating random pointer pairs 
is valid. You can inspect the code in the pull request (https://bitbucket.org/jendrikseipp/downward/pull-requests/73).
History
Date User Action Args
2017-09-01 13:59:46jendriksetmessageid: <1504267186.71.0.664273331904.issue731@unibas.ch>
2017-09-01 13:59:46jendriksetrecipients: + jendrik, malte
2017-09-01 13:59:46jendriklinkissue731 messages
2017-09-01 13:59:46jendrikcreate