この記事は TSG Advent Calendar 2023 17 日目のエントリです。

TL;DR

Google Summer of Code 2023 でLLVMにProposalが採択され、Midterm/Final Evaluationに通ることができました。今後の応募に参考になりそうな技術的な内容は以下の外部リンクから辿れるものが全てだと思います。

Project Description + 採択前の会話の残った Discourse

[LLVM] Addressing Rust optimization failures in LLVM - #9 by nikic - GSoC - LLVM Discussion Forums

Proposal GSoC 2023_Proposal_Addressing_Rust_optimization_failures_in_LLVM - review(draft) - Google ドキュメント
Final Report docs.google.com

また、プロジェクト中に取り組んでいたRustのmove向けの最適化について、2023年7月のKernel/VM探検隊で早口で紹介をしました。

www.youtube.com

以降は採択前からプロジェクト終了までやったことを細かめに、応募やプロジェクトの進行に対する不安を取り除けたらいいですね、という建前でダラダラと書いていきます。

採択まで

前々から憧れの先輩方がやっていたGSoCに興味はあり、一応学生最後の年なので*1応募はすることに決めました。しかしいろいろあって自信を失っており、比較的小さめなIssueをプチプチ潰すことしかできないと考えていました。何のプロジェクトでプチプチしようかと、2022年のプロジェクトリストを眺め、憧れのOSSであったLLVMのIdea listを眺めることにしました。

idea listを眺める

Latest GSoC topics - LLVM Discussion Forums

2023年のアイデアでは以下の２つが気になりました。

[LLVM] Addressing Rust optimization failures in LLVM - GSoC - LLVM Discussion Forums

[LLVM] Improving compile times - #2 by 0xdc03 - GSoC - LLVM Discussion Forums

Rustは使った経験があり、ゴールが明確に設定しやすく楽しそうでプチプチ思想とマッチしているRustのoptimization failuresのプロジェクトに狙いを絞りました。

また、憧れの先輩や友人をご飯に誘ってアイデアリストの話をして、アドバイスをもらったりしました。プロジェクト選びはかなり大変な気もするので、彼らが話をしてくださらなければ、きっと僕のGSoCへのモチベは雲散霧消していたことでしょう。

build環境を整える + コミットのマナーや雰囲気を知る

メンターの方が書いていたllvmのビルド + コミットマナー + ミドルエンドの入門に良ブログポストが公開されていたので、それに習ってビルド環境を整えました。 developers.redhat.com Phabricatorは最初怖かったですし、*2この記事がなかったらビルドもできず、Patchも作れていなかったと思います。

また、この時点で過去のGSoC LLVMの人々/メンターさんや気になった人々のLLVMへのPatchを初期の方から眺めるみたいなこともしました。効率よく今のソースコードの知識を得るにはよりよい方法がありそうですが、個人的には心理的な不安を取り除いたり、レビューの雰囲気を知るのに役にたったと思っています。

Project DescriptionにあるIssueに取り組んでみる(と言ってみる)

Project Description を見るとわかりますがRustはキャッチーだったので結構興味を持つ人が多かったです。これに焦り、とにかく他の人より手を動かして早くリーチアウトせねばと思い、テストを足すだけでしたがパッチを作って、方針を当時わかる限り書いてメッセージを送りました。

Patch作成・コード/LangRef読み・Q&AとchatGPT

上記のパッチをマージするべく頑張りました。また関連するパスのソースやLangRefを読んだりしました。

DiscordやDiscourseの他人の質問をchatGPTにそのまま投げて*3返答の真偽を確かめたり*4してました。他のOSSではどうかはわからないですし、今となっては普通のことかもですが、LLVMの場合は初歩的な疑問は雑にChatGPTに聞くと、関連するソースコードやキーワードの見当をつけるのにはいい回答を結構してくれるなという印象でした。*5

Proposalを書く

結局Proposalを出す時に、手を出したIssueは完全には解けませんでしたが、方針は立ててPatchのDescriptionとProposalに書きました。

Project Description、既存のPatch、先人の方々の申請書を読みながらProposalを書きます。ある程度できたら元インターン先の同僚や友人に、スケジュールの切り方について相談したり、全体的な流れなどを見てもらいました。彼らの助けがなければ多分Proposalすら出せませんでした。ChatGPTにもたくさん助けられた気がします。

GSoC 2023_Proposal_Addressing_Rust_optimization_failures_in_LLVM - review(draft) - Google ドキュメント

Deadline 二週間前くらいにメンターの方に添削もお願いしました。

採択後

採択のメールが届いた後、メンターさんに連絡すべきかな〜と思って過ごしていたら、Congrats! ... とメッセージが来たので、コミュニケーションの取り方をどうするか確認しました。

weekly video meetingを希望したら快く承諾してもらえ、それ以外はPatchのDiscussion + DiscourseのDMで進めることになりました。

最初のミーティングでは進め方を話したり、自分のアイコンがちさとであることを指摘され、日本のアニメの話をしたりしました。日本のアニメ、すげーと思いました。【推しの子】を未視聴だったそうなので、視聴をオススメしました。

Amazon.co.jp: 【推しの子】を観る | Prime Video

コミュニティに馴染むためのCommunity bounding periodが設定されていますが、特に気にしないでそのまま開発がはじまっていました。

毎週のミーティング

共有Google Docを作って、Patchを作りながら疑問/方針のメモに使い、自力で解決できなかったことを聞き~~たまに少しアニメの話をする~~ 、という流れで進めました。

Patchに直接的に関わることはPatchのReview内で聞き、それ以外の慣習や気持ちを聞くことが多かったです。

Midterm Evaluation

メンターさんのこと、コミュニティのこと、自分のプロジェクトの進捗についてのアンケートに答えます。特に頭を悩ませることはありませんでした。

提出したらメンターさんからFeedbackがもらえます。僕の場合は「概ねよいが強いて言うなら書き英語が改善の余地あり。」という感じでした。

Final Evaluation

作ったPatchをベースにFinal Reportを書きます。期限内にメンターさんと内容の確認をして、レギュレーションを守ったドキュメントを提出できれば特に問題はないと思います。

Addressing Rust optimization failures in LLVM | [“GSoC 2023 LLVM Final Report”]

提出したらメンターさんからFeedbackがもらえます。僕の場合は「Weekly meetingが楽しかったし、素晴らしかった。」といってもらえました(涙)。

しかし依然としてDescriptionやコメントを書く時にtypoやgrammerミスを連発してしまい、Final Evaluation提出後にようやくSpell checkerをエディタに導入しました。これは結構大きめの反省で、レビューされるテキストを書くなら最初から導入すべきでした。

おわりに

Rustのmoveにまつわる最適化をはじめに、個人的に興味のあったことに取り組めたのでかなり楽しく、有意義でした。

それと同時にサクッと実装した最適化のプロファイルができずPatchの説得力がなくなってしまったり、実装に時間がかかったり実力不足も痛感しました。開発経験や能力は応募時にあるほど成果をだしやすいのは事実ではあると思います。実際自分も事前に関連する道具を使った経験がなかったら今回より輪をかけて何もできていなかったとは思います。

とはいえ比較的泥臭いだけのIssueでも、ある種の実用的で巨大なソフトウェアの開発を学べるという点で非常にためになったので、時間があり、興味のある任意の方にGSoCはおすすめです。僕のように修士2年になってからではなく、興味のある学生の方は早めに自信がなくても、会話して応募するだけでも研究のテーマ決めや社会とのあれこれにも生きる気がします。

また、メンターさんのもう一つのLLVMのコンパイルタイムを短くするプロジェクトはこちらのよりもふわっとしているのでメンティーは最初苦労していたそうですが、最終的に良い成果を出せているなあと感じました。そちらもメンティーの方のブログ等で詳細が公開されているので、興味のある方は読んでFinal reportなどよんでみると面白いかもしれません。

[LLVM] Improving compile times - #2 by 0xdc03 - GSoC - LLVM Discussion Forums

dc03 ·

拙い文章でしたが、どなたかの今後の参考になれば幸いです。

最後に自分が参考にした資料を載せます。インターネットの先駆者や様々な人に本当にお世話になりました。この場をお借りして感謝申し上げます

追記: 今回のブログ、思ったよりも多くの方に見てもらっていそうです。 Patchをよく見るとわかるかもですが正直自分よりもふさわしい能力を持ってる人はたくさんいて、自分は度胸と時間が少しあっただけで機会を奪ってしまった感があります... 実際僕はパフォーマンス改善よりも多くの複雑度を追加した感がすごいです。自分はこれを糧に強くなるしかないなと思うのですが是非僕のPatchや直接ソースを読んで、なんだこれ...と思った人は是非Patchを書いてみてください!*6 メンターさんをはじめとした近年のContributorさん達により、Compile-time Regressionを可視化するインフラも整ってきていて*7、ミドルエンドの最適化が複雑になりすぎることの問題意識も高まっている気がしており*8、いい意味で未熟なPatchを書いてもリリースされて悪いことは起きないと思います!

遅刻してしまいすみません。また本来は最近話題のClangのk乗和の最適化に使われるScalarEvolution(SCEV)とLoopVectorizeのIssueについて書こうと思ったのですが、 Scalar Evolution自体のブログは既にあったり、k乗和の解説も詳しくて、それより価値のあるブログを書くのには諸々間に合わなかったのでmugさんからリクエストをいただいたGSoCの体験記を書きました。