thumbnail-sp
thumbnail

樋口 兼一

エンジニア

MN-Core ソフトウェア

※本記事は2023年10月に取材したものです。サービス名称や所属は取材当時の内容です。

自己紹介をお願いします

2020年に入社し、MN-Core用のソフトウェアを書いて今年で4年目になる樋口と言います。大学院では電子情報学専攻に所属し、並列プログラミングの研究をしていました。今はMN-Coreを使った機械学習の高速化を仕事にしています。プログラムの高速化にある総合格闘技感が好きです。

現在担当している主な業務内容や具体的な流れについて教えてください

自分はコンパイラチームと呼ばれるところに所属していますが、ここではコンパイラの実装だけではなくランタイムや計算カーネルの実装、及び社内ユーザーのサポート(主に性能や速度のチューニング)も行っています。これらのソフトウェアスタックの開発をチーム内の小部隊で分割して担当し、週2回程度の全体ミーティングで擦り合わせや複数のレイヤにまたがる最適化などについて相談しています。その中でも自分は計算カーネルの実装をメインとしていて、心の赴くままにアセンブリを眺めつつ改良策について考えています。その過程でコンパイラ本体のバグや問題に遭遇することは良くあり、それらに対して改良案を考えたり実装することも自分の仕事です。

チーム全体の短中期的な指標としては、多種多様な機械学習モデルの処理速度を採用しています。頻度はモデルによっても異なりますが、それらの計測は自動的に行われ、結果が継続的に記録されています。そしてどのくらい速くなったかを週に1回のミーティングで確認することで、今期の目標に対してどのくらい進んでいるのかが簡単にわかるようになっています。これだけ聞くと高速化しかしないように聞こえますが、高速化に直接影響しないような変更もソフトウェアの品質を高めるようなものであれば良いですし、誰がどのくらい高速化したかというのも重視はされていません。このように大まかにチームの方向性を定める程度の指標となっています。

ミーティング等のコミュニケーションは基本的に全てリモートで完結しています。そのためメンバーの中にはほぼ出社せず、業務後の懇親会などでビールが提供される日にだけ出社する、といった方もいます。もちろんその逆に出社した方が捗るという方もいます。週に1回の頻度で出社日を設けていますが、コンパイラチームでは、実際に出社するかどうかは個々人の判断に任されている為、PFN全体から見ても相当に自由な働き方が出来ていると感じています。

入社してから現在まで PFN で成長したと感じることはありますか?

読者の方々にとって馴染み深いであろうデバッグについて書こうと思います。

自分が入社して2ヶ月頃、スパコンのコンペティションであるTOP500/Green500へのランキング入りを目指すチームに投入され、LINPACKと呼ばれるベンチマークに含まれる行列・行列積の高速化を担当しました。元々インターンシップ生としてMN-Coreのアセンブリについてある程度経験があったこともあり、高速化作業自体は順調に進んでいました。しかし、ある時から正しくない計算結果が返ってくるようになりました。

当然、実装を疑って処理中のループを切り分けて調べるわけですが、どこの処理も正常に動いている。ほとほと困り果てて先輩方に助けを求めたところ、プロセッサに供給する電力設定の不備を指摘されました。それを修正してみると確かに正しい結果が返ってくる。このチャレンジは幸いにもGreen500ランキングの1位という結果で終えることが出来ましたが、当時はこの謎の現象について高速化が進むと発生するということしかわからなかったため、再発に怯えながら作業していたのを覚えています。

コンペティションの終了後に先輩の指導の元で原因究明したところ、計算処理の軽いループの先頭と処理の重いループの末尾の境界に電力供給の波があり、それが原因で計算間違いが発生していました。言ってしまえば単体テストは通って統合テストで通らない原因を見つけるのに苦労したという話ですが、その原因が電力供給装置が処理のループをまたいで状態を持つため、というのは中々体験出来ないのではないでしょうか。

当時は各処理の正しさのみに注意が行っていた為、本当に問題の起きている箇所を含んだ検証が出来ていませんでした。先輩からその仮説が間違っている可能性を指摘されることで、ようやく正しい場所を検証出来たという訳です。

その他にも機械学習ワークロードをMN-Core上で動かすには多くの壁があり、MN-Coreでの処理が間違っているのではないかと言われて頼まれて調べた結果、全く別のところが問題であったり、その逆であったりと難易度の高いデバッグは多数存在します。そうした中で仮説を立てて問題を切り分けていくのはデバッグの基本ですが、時には全体を俯瞰して見る必要があります。問題を適切に切り崩していくデバッグ力は、PFNでの多様な実務を通じて着実に身についていると感じています。

PFN に入社して良かったと特に感じる経験はありますか?

自分がPFNで特に気に入っているものに「まず先に褒める文化」があります。ここで言う「まず先に褒める」というのは、例えばサンプルプログラムを動かせるようになったといった些細な進捗報告に対し、聞き手側が最初にさりげなく褒めることを指します。これにより話し手側が裏でどのような苦労があったかなどを話しやすくなります。

成果が思うように上がらないことも時にはありますが、それでもその背後にある試行錯誤やそこから得られる知見を共有することには技術的な価値があり、その認識が社内全体にあるからこそ、このような文化が自然に根付いているのだと考えています。また、同じ褒めるにしても見当外れなものではなく、その内の貢献を取り上げて適切に褒めるべきです。それには褒める側にも相応の知識と経験が必要であり、それが社内全体で自然に出来るというのは素晴らしい環境だと思います。

最後にメッセージをお願いします

PFNのこのようなページを読む皆様には、近い将来(主にIT)技術を主軸に生計を立てていきたい方が多いのだと思います。学生の内は興味の赴くままに色々なものを試してみて、その先にPFN及びそのチップ・コンパイラチームがあればとても喜ばしく思います。

Preferred Networksを
もっと知る

Contact

お問い合わせはこちらまで。