LFX'22 RISC-V Mentorship 体験記
本記事はeeic(東京大学工学部電気電子・電子情報工学科)| Advent Calendar 2022の19日目の記事として書かれたものです。
はじめに
どうもEEIC2021の@takutaku3です!自分には特に定まったUser IDがなくてサービスによって使うUser IDが異なっているので、全部同じUser IDに統一したかったなーと今頃後悔しています。ちなみにGithubは@tak-ka3であり全く違うUser IDですよね。
本日は自分が参加したLFXのRISC-V Mentorshipでの経験をシェアしたいと思います。このプロジェクトの日本人の体験記事は私が調べた限り見つからず、まだまだ日本では浸透していないように感じたのでもっと広まって欲しいと思い今回記事を書くことにしました。そのため技術的な詳細というよりはこのプロジェクトの概要が中心となっています。以後このプロジェクトをMentorshipと呼びます。
LFX Mentorshipとは
まずLFXというのは、Linux Foundationというオープンソース活動を支援する団体が提供する様々なサービス群の総称で、その中の一つとしてMentorshipがあります。ちなみにLinux Foundationは日本リージョンも存在しています。Mentorshipは2019年からスタートしたのでできたばかりのようですね。Mentorshipには様々なプロジェクトがあり、Linux kernel, Meshery(Kubernetesマネージャー), OpenDaylight(SDNプラットフォーム)など多岐に渡っています。ここからプロジェクトの一覧を見ることができます。私はその中の一つ、RISC-V InternationalがホスティングしているRISC-Vのプロジェクトに申し込みました。自分が選んだプロジェクトに申し込み、採用されたらMentorの指導の元と一緒にOSSの開発に取り組むというのがMentorshipの流れで、非常にGSoC (Google Summer of Code)と近いと思います。プロジェクトの詳しい内容は後述します。
Mentorship参加までの流れ
まずMentorshipは、たまたまtwitterで以下のようなツイートを見かけたのがきっかけで知りました。ありがとうございました!(ちなみにこの方がチャンスを私にくれたように私の記事を見てチャンスを得ることになる人が増えるといいなと思い、私も参加したら記事を書こうと前々から考えていました。)
ただ、文字面だけではどのようなプロジェクトかイメージが湧きませんでした。というのもMentorshipに関する日本語の記事はないのはもちろん(申し込んで通らなかったという記事はありましたが体験記はありませんでした)、海外の記事もほとんどなかったからです。それなのに申し込んだ理由としては以下が挙げられます。
OSSへのコントリビュートに興味があった
海外のエンジニアと関わる機会を得てみたかった
研究などを含めRISC-Vの関連技術に触れる機会が多くさらに深めたかった
これらはもちろん本心ですが、当時必死にやっていた院試勉強から早く解放されたいという思いが申し込みを後押ししたようにも感じます。
早速申込書を書いたわけですが、申し込んだ理由や得意な技術領域、経歴などという日本のインターンの申し込みでいかにも聞かれそうな質問事項ばかりでした。ただもちろん海外のプロジェクトなので全て英語で書きました。また履歴書も提出が求められ、これが日本の履歴書とは異なり社会奉仕の経験や自分のパーソナリティなどを書く必要があり、書くのに時間がかかりました。しかし院試勉強の最中ということもあり、やや手抜きの履歴書になってしまいました。就活、インターンなどでもこの申し込みのフェーズは必須ですが、正直ここが一番面倒くさいですよね。。。まあ相手は自分が何者か知らないので当然大事。
院試が終わってから以下のようなメールが届きました。
合格!嬉しい!!!ただよく見ると、"UNPAID"…
どうやら選考を1位通過しないと、給料は出ないようです(選考1位通過の人は1週間20時間コミットを6ヶ月で3000USDももらえるらしい!(◎_◎;))。ただ、「経験はお金に換えられない!!!」というありきたりなことを思いプロジェクトを快諾しました。
Mentorshipの内容
私はRISC-Vプロジェクトの中でOpenBLASというプロジェクトを選びました。OpenBLASというのは、線形代数演算ライブラリであり、ベクトルとスカラ同士計算であるLevel1、行列とベクトル同士の計算であるLevel2、行列同士の計算であるLevel3に分かれています。また主にインラインアセンブリを用いて書かれたライブラリであり、ISAやプロセッサごとに最適化されています。OpenBLASの使用例としては、PythonのnumpyやJuliaの裏で走っていることもあるそうです(走っていることもあると濁したのは、OpenBLASの対抗馬であるintel MKLが使われていることもあるからです)。このOpenBLASは、元々後藤和茂さんという日本人の方がGotoBLASという名前でやっていたソフトウェアを引き継いでできたものなので、そこに同じ日本人としての何か縁を感じました。
そして私はこのプロジェクトで、RISC-Vのベクトル拡張のバージョン1.0をLevel-3(行列同士の計算)に対応させるという機能改善に取り組みました。
Mentorshipの様子
プロジェクトの期間としては3ヶ月(まだ継続中)で、メンバーはOpenBLASを作った中国籍のMentorの方と、僕と同じくプロジェクトに取り組むロンドンの大学生であるMoazzamの3人でした。ミーティングはzoomで週1回30分程度、基本的な連絡はSlackで行いました。最初はTelegramで連絡を取るということになったのですが、Moazzamがどういうわけか使えないという理由でSlackに移行しました。このように多国籍でプロジェクトを行うと、使用するツールも気にかける必要があるということに新鮮さに感じました。
そして多くの人が気になると思う英語でのミーティングについて。私自身海外へ行ったことがないので、最初zoomで海外の方と繋がった時は「本当に現実なのか?」みたいななんとなく不思議な気持ちになりました。私は英語が苦手なのですが、実際のミーティングでは全員で共通するソフトウェアに関する議論をすることになるので、相手が言っていることはある程度理解することができました。また、こちらが喋る時もとにかく伝えようとして何か話せば相手がある程度汲み取ってくれるので、総じて意思疎通はあまり問題ありませんでした。ただMentorの方の英語を話すスピードがゆっくりだったので、そこも非常に助かりました。またどうしてもミーティング中に理解しきれなかったことはMoazzamに聞くことで解決していました。
次に、その一緒にプロジェクトに取り組んだMoazzamについて。彼は大学でCSを専攻していてOCamlに関するOSSに取り組んだ経験があるというようなバックグラウンドでした。コンピュータアーキテクチャの知識やアセンブリに触れるような機会がなかったようなので、完全に興味本位でこのプロジェクトを申し込んだと思われます。ただその状態からキャッチアップするのはかなり大変なので、彼はかなり必死に勉強したようです。そんな彼には色々学ぶことがあったし感謝しています。
まずこのプロジェクトへのパッションが非常に大きく、それを最初の自己紹介で全力でMentorの方にぶつけていました。私は日本人気質なのか何なのかわからないのですが、そういう自分の中の感情をそれがポジティブ過ぎるほど、言葉にして伝えるのを照れ臭く思ってしまいます。ただ、とりわけポジティブな気持ちを伝えることはプロジェクトの士気を上げることや相手とのコミュニケーションを円滑にすることに間違いなくプラスに作用するので、とても大切なことなのです。もちろん人生の様々な場面で、気持ちを言語化して人に伝えるというのは大事ですよね。
似たようなことですが、ミーティングが2週間連続くらいでなかった時、彼がMentorの方に「なぜなかったのか?」「ない時は事前に理由を説明してほしい」「土曜日ができないのなら別日に振り返るのはどうか?」というのを柔らかい言い方で伝えており、自分の感情・考えを適切な形で言動に移す能力が高いように感じました。自分はMentorの方も忙しいのだろうと勝手に推察してそのような発言を躊躇っていましたが、もっと自分を優先してそのような発言をするべきだと感じました。またMoazzamとは技術的なサポートもお互いし合っており、総じて感謝しています。
Mentorshipを通して学んだこと
OSSのコントリビュートに対する障壁の低下
私自身OSSにコントリビュートした経験はありません(eeicの「大規模ソフトウェアを手探る」という授業でvscodeにコントリビュートしようとはしましたが、マージはされていません)。そのためMentorshipを始めた当初は、OSSにコントリビュートすることは偉大なことで、本当にコントリビュートできるのか不安でした。しかしプロジェクトを進める中で意外とそこまで障壁が高くないということに気づきました。一つ一つ手順を踏んでいけば、そのステップのゴールにコントリビュートがあるのです。一応以下が私が実際に踏んだステップです。
OpenBLASのコンセプト及びアルゴリズムを理解するために、x86向けの最適化チュートリアルを進めたり、関連する論文を読む。
コンパイラ、シミュレータの環境構築
GEMM(行列同士の積)のための4x4 kernelを、RISC-V ベクトル拡張のIntrinsicsを用いて書く。
GEMMのための4x4 kernelを、RISC-V ベクトル拡張のアセンブリを用いて書く。
新しいソフトウェアのバージョン管理の難しさ
ソフトウェアは日々機能改善・修正を繰り返してより良いものになっていきますが、その中でも大きな機能拡張というものがたまにあります。その機能拡張が公に公表されると、バグは少なからずあるのですが、基本的には開発者が想定しているテストをpassして一通り動作が正常であることは確認されています。ただ、実行環境やバージョン、他のソフトウェアとの兼ね合いなどで往々にして実行できないということを改めて身をもって実感しました。具体的にはRISC-Vのgccはこのリポジトリで管理されているのですが、RISC-Vのベクトル命令は割と新しく導入された命令拡張であるため、コンパイルすることができない、シミュレーションが走らないなど様々な問題が生じました。問題なく実行できる人もいるようでしたが、私の環境ではなかなか実行できず非常に苦労しました。多分ここ1ヶ月以内では、日本で一番RISC-Vのgccをビルドしていたと思います。そんな苦労もあり、誰かが既に試していてそれに関する技術ブログがあるということは当たり前ではなく、実はかなりありがたいうことだったと改めて感じました。ビルドエラーとそれの対応策をログとして残しておいたので、これから私と同じことをしようとする人のためにまた別の記事でまとめるつもりです。
ただこの試行錯誤は無駄なフェーズではなく、gccとclangの違いやglibcとnewlibの違いなど学ぶことが色々とあったので、前向きに捉えています。issueを立てることの障壁の低下
issueを自分で走らせているプロジェクトで立てることはあると思うのですが、外部のOSSでissueを立てることはあまりないと思います。私自身も一回もなく、自分なんかがissueを立ててもいいのか?という控えめな気持ちが先行して最初はissueを立てることに躊躇してしまいました。しかし、他のissueを見ていると意外と初歩的な質問や他のissueと重複した質問をしており、他のissueを見た上で重複しておらず本質的な内容だと思ったら提出して全く問題ないと思い直して提出しました。
↓私が立てたissue(なんか微妙に未解決なのでまだOpen、、、)
まとめ
以上が私のMentorship体験記でした。ただ実はまだプロジェクトは終わっていないので、終わった後にまだ補足したい事項があったら追加で記事を書くかもしれません。また技術的な学びも非常に多かったですが、それもまた別の機会に触れようと思います。
ぜひ皆さんにもこのMentorshipに参加してほしいです。1週間に20時間程度のコミットが求められると確かに躊躇してしまう気持ちはわかります。私もB4は卒論研究を頑張りたいという気持ちがあったので迷いましたが、結局バイトを最低限に抑えることでなんとか両立させています(多分)。
そのOSSのスペシャリストであるMentorから手取り足取り教えてもらいながら、OSSの開発を進めるというのはOSSの世界に入る第一歩としてはちょうど良いだけではなく、このプロジェクト自体かなり貴重な経験になるはずです。私自身参加して良かったと思っています。
長文でしたがここまで読んでいただきありがとうございました!
この記事が皆さんの何かの参考になってくれたら幸いです。
補足:1/19のPM 12:07(JST) に成果報告会みたいなもので、"Opening the door to the Open Source Software through the OpenBLAS prooject" というイケてる題名で発表しました!Youtubeで観られます!