manabinohibi
commented
1 year ago microsoft/pmwcasの方のコードも読んでflushの回数なども数えたのですが，成功するパターンであれば自作もmicrosoftもflush回数は同じだったので，microsoft側が永続化をさぼっているなどではないようです．
ありがとうございます．そうなんですね，microsoft/pmwcasは割とスケールするので不思議なところです．
論文では実験結果などから色々と考察してみてください．
了解です．修論の考察として考えてみます．難しいですが…
なんかもうちょっと性能でないかなと思って少しだけコードをいじりました（ただしそんなに効果はない）．最初のコミットはビルド時の警告を消すためのものなので無視してもらって，他3つだけ見てもらえればOKです．
性能的に一番影響してるのはおそらくハードウェアの使い方に関する部分で，このコミットでは記述子のアラインメントを64バイトから256バイトに変更していて，これによって56スレッドでのスループットが5.9Mから6.5M程度まで向上します．これはおそらくPMEM上での読み書きの粒度に起因するもので，本来記述子は各スレッドで1つを専有するので一切競合なく読み書きできるはずなんですが，アライメントをちゃんと指定しないと2ないし3つのスレッドでPMEM上の読み書きで競合が起きて性能が下がってしまうのだと思います．
ただ，性能がスケールしないのは未解決です．microsoft/pmwcasの方のコードも読んでflushの回数なども数えたのですが，成功するパターンであれば自作もmicrosoftもflush回数は同じだったので，microsoft側が永続化をさぼっているなどではないようです．PMEM_NO_FLUSH=1を指定した状態で動かすと自前の方がmicrosoftの倍以上の性能になるので，永続化部分がボトルネックになっている（PMEMのハードウェアとしての使い方に何か非効率的な部分がある？）のだとは思うのですが．たぶんここが一番の考えどころなので，論文では実験結果などから色々と考察してみてください．