generator.pyの並列化対応 / generator.pyの高速化 about library-checker-problems HOT 11 CLOSED

とりあえず放置 限界が来たら再open

from library-checker-problems.

GitHub Actions での並列化を検討してるならついでにこっちもしたいです
(速度は 2 倍ぐらいにしかならないが、実装は楽かつ利用もオプション付けるだけで簡単なため。手元実行や verify-helper にも恩恵がある)

from library-checker-problems.

@yosupo06 これやるとしたら仕様はどう考えてますか？

1. デフォルトで有効にするか、オプションで指定するか
   • 自動で使われてほしい気持ちはある。でも不安定になりがちだし常に CPU 100% はうれしくない気がする
   1. オプションで指定するならその名前は何か
      • make や GNU parallel などの -j --jobs 派が標準的だしこれに合わせておくと分かりやすそう。もちろん --num-parallel とかの選択肢もあります
2. 実装において、どこを並列化するか
   • 実装の手間を考えるとどこかひとつの for loop をN倍速にする感じになります。このとき (a.) 問題ごとに1スレッド割り当てるか、(b.) 問題は順番に処理してそのテストケースごとに1スレッド割り当てるか、のどちらかになりそう。(a.) だと手元で -p で指定したときに無力でうれしくない、(b.) だと並列化できない部分がでてきてアムダールの法則がすこし影響します。もちろん ad-hoc に (a.), (b.) 切り替えもできるが面倒

とりあえずの実装は -j 2 みたいに指定してテストケースごと並列がよいと思ってます。

from library-checker-problems.

あまりやる気が起きていないです　手間に対して利点が薄いと考えているからです

ざっくり分けて(使用者側 / 開発側) * (CI / 手元)で4種類の用途があるはずで

• 使用者 * CI : 利点1でしょうか　しかしケース生成がボトルネックになるというのがあまり想像ついていないです
• 使用者 * 手元 : 再生成を防ぐ機能がついているので、ボトルネックになるとは思えません
• 開発側 * CI: 将来的に必要になるかもしれませんが、Action20並列とかの方が効果が大きいと思います(そしてこれでも遅すぎるようになったら、2倍で延命するより自明な部分を再チェックしないとかの機構を考えないといけない段階だと思います)
• 開発側 * 手元: 利点2 ですが並列化してlogの出力順序や実行時間が不安定になることを考えると、結局あんまり使わないんじゃないかという気がしています

from library-checker-problems.

これ会話に失敗していることに気づきました　やるとしたらの話だとkmykさんに同意します

• 問題並列 vs ケース並列: ケース並列でいいと思います(問題並列だといよいよ旨味がなくなるのでは？)
• -jだと他のオプションに対して1つだけ異様な感じがするんですが、しかしこういうので-jが一般的だというのは強く同意するので、これでいいと思います

from library-checker-problems.

主にほしいのは利点1 (使用者 * CI) です。
20並列と比べて利点がかなり薄いのは正しいんですが、実装の手間はそんなに大きくない (多くて20行くらい？) ので、とりあえず簡単に削れるところから削っていきたいという気持ちです。

from library-checker-problems.

実装は私がするつもりなのでその手間は無視してよくて、メンテコスト (オプションを増やしたくなさ + コードを増やしたくなさ) と多少の効果とのどっちをとるかの選択になっているはず

from library-checker-problems.

うーん　実際にCIの利用者が遅いと感じているならば追加するべきだとは思いますが、観測されていますか(逆に感じている利用者がいないなら、利点が消えるので実装するべきでないと思います)？

例えばhttps://github.com/kmyk/online-judge-verify-helper の利用者一覧のActionsを適当に眺めても、基本的に4~5分の範囲に収まっているように思えます(私が慣れてしまっただけで、実は4,5分でも長い？)

例:
https://github.com/beet-aizu/library/actions
https://github.com/kmyk/competitive-programming-library/actions

from library-checker-problems.

4~5分は CI としては短めですが、verify-helper だと CI が終わらないとできない処理がある (自動で commit が push される仕様のためにCIが終わるまで追加の push ができない、CIが生成したドキュメントのCopyボタンを使って問題提出をしたい) ので可能なら短くしたいです。

(ところで、有用性に関する議論が長引くということは実装しない方がよい気がしてきました。ひとまずやめておこうかなと思います)

from library-checker-problems.

CIが4,5分でもネックになりうるのは理解しました

あまり急を要するissueではないと思うので、とりあえずこのissueはopenで残しておきます　遅いと感じてここに行き着いた人はemoticonなどを付けていただけると

from library-checker-problems.

今の所特段の需要はなさそうと判断し、一回closeします

from library-checker-problems.