v1:
https://ai.dmi.unibas.ch/_experiments/ai/downward/issue1105/data/issue1105-v1-eval/issue1105-v1-issue1105-base-issue1105-v1-compare.html
Strangely enough, with the sbMIASM merge strategy, there seem to be a significant slow down in M&S computation time, or at least significant fluctuation. The only difference in terms of computation I see is how the remaining factors, once all SCCs have been dealt with (= all of its variables have been merged), are treated. In the old code, the remaining factors are considered in the same order as the SCCs whereas in the new code, they are considered in lexicographfic order. By "considered" I mean that the merge strategy computes the merge candidates (all pairs of factors) based on a possible different order, which also means that merge candidate pairs could have their "first" and "second" factor swapped. According to the number of expansions, this doesn't change the decision made by the MIASM scoring function.
I tried to reproduce the runtime differences both locally and on login-infai, using the compiled code of the experiments, but failed in both cases. (Tested instances: blocks-8-0 and depot/p02.) blocks-8-0 has a *single* SCC, so the computation of both base and v1 are *identical*, but just takes more time in one case compared to the other.
v2: https://ai.dmi.unibas.ch/_experiments/ai/downward/issue1105/data/issue1105-v2-eval/issue1105-v2-issue1105-base-issue1105-v2-compare.html
In v2, I added a vector.reserve() when computing the list of remaining factor (indices). The picture remains the same: construction time changes in both directions, with a significant part into larger construction for v2 compare to base. The same two instances I checked previously are now "fine", but others which were similar before are now very different.
Actually, now that I compared just the base version from the two experiments, they alone already exhibit that large difference in times in some instance. I think others previously also observed such large differences on our cluster. I would therefore attribute the results to noise. Anyone has other thoughts or ideas?
|