实测结果问题 about acqdp

[Z-Y00]

Maybe you need to configure the search time? I think they have much longer search time in their paper than the default config in this repo.

[chenkenshin]

I will let my colleague to address the first question. For the second one, @Z-Y00 , you are right the parameters we used to generate those orders are different from those in the default config file, one can always change parameters to those we reported in the paper and regenerate our orders though.

But @LL-Math 's question is more about his estimated cost of the reported order is higher than what we reported in arXiv:2005.06787. The caveat is that opt_einsum assume REAL FLOPs which in this case is 2x the actual 'contraction cost' reported in our paper. This issue was first mentioned in arXiv: 2002.01935, "assuming every contraction is an inner product, for real (complex) tensors, the associated FLOP count will be a factor of two (eight) times more than the actual contraction cost. "

Therefore, when report the actual contraction cost, we should divide the reported order.cost by 2. I hope this has addressed your concerns.

[fangzh-umich]

I will note that usually the first subtask takes more times than the rest: The JAX backend of einsum performs lazy compilation, which takes place while evaluating the first subtask. Therefore maybe you should either use more than a few subtasks to estimate the running time, or exclude the first subtask from the timing.