代替実装の問題 | ポインター ゴーン ワイルド

この投稿では、私がソフトウェアの世界で何度も何度も見てきた力関係について話したいと思います。 実際、このような状況はおそらくハードウェアの世界でも同様に起こるのではないかと思いますが、ここでは私の経験があるのでソフトウェア システムについて話します。 このディスカッションでは、人間の心理学について少し触れ、よくある罠について概説します。そうすれば、皆さんが罠にはまることを避けることができます。

私のキャリアのほとんどは、学界でも産業界でも、動的に型付けされたプログラミング言語の最適化に費やされてきました。 修士課程の間、私は簡単な最適化に取り組みました。 MATLAB 用の JIT。 博士号取得のために私は次のことに取り組みました JavaScript の JIT。 今日はYJITという最適化に取り組んでいます。 RubyのJIT これは現在 CRuby にアップストリームされています。

博士課程の在学中に、独自の JavaScript JIT に取り組みながら、他の動的言語の JIT コンパイラーに関する多くの論文やブログ投稿を読みました。 HotSpot、Self、LuaJIT、PyPy、TruffleJS、V8、SpiderMonkey、JavaScriptCore などの設計について読みました。 また、これらのプロジェクトの背後にいる多くの本当に賢い人々と交流し、直接会う機会もありました。

私が印象に残ったことの 1 つは、PyPy プロジェクトが奇妙な場所で行き詰まっているということです。 彼らは、Python 用の高度な JIT コンパイラを開発しました。 大幅な高速化 CPython よりも。 どう考えても、多くの人がこれらのパフォーマンスの向上から恩恵を受けることができますが、PyPy は「現実世界」ではほとんど使用されていませんでした。 彼らが直面した課題の 1 つは、Python が動くターゲットであるということです。 CPython の新しいバージョンは定期的にリリースされ、常に多くの新機能が追加されていますが、PyPy はそれに追いつくのに苦労しており、常に Python のバージョンが数バージョン遅れています。 Python ソフトウェアを PyPy と互換性のあるものにしたい場合は、使用する Python 機能がさらに制限されるため、ほとんどの Python プログラマはそのことについて考えたくありません。

LuaJIT について読んだところ、これは今も昔も高く評価されていることがわかりました。 多くの人は、その作成者である Mike Pall を素晴らしいプログラマーだと考えています。 LuaJIT が提供するもの 素晴らしいパフォーマンス デフォルトの解釈された Lua 実装よりも優れており、実際にある程度の適切な採用が見られます。 しかし、Lua 言語は新しい機能を追加し続けており、LuaJIT のバージョンは数バージョン遅れているため、Lua JIT を使用したくない Lua ユーザーが多数いることを改めて知りました。 Lua がミニマリズムで知られる言語であることを考えると、これは少し奇妙です。 新機能の追加を遅らせたり、Mike Pall と調整したりする努力もできたように思えますが、それは行われませんでした。

約 4 年前、私は Ruby に取り組むために Shopify に入社しました。 何らかの理由で、Ruby JIT の領域は特に競争が激しく、Ruby JIT を構築するプロジェクトが多数存在していました。 TruffleRuby JIT は最も印象的なパフォーマンス数値を誇っていましたが、やはり展開は限られていました。 これには実際的な理由がいくつかあり、TruffleRuby のウォームアップ時間は CRuby のウォームアップ時間よりもはるかに長いですが、CRuby が機能を追加し続けるため、TruffleRuby のコントリビューターはハードワークを必要とする PyPy や LuaJIT と同様のダイナミクスも見られました。頑張ってついていきましょう。 Ruby ユーザーは常に CRuby を正規の実装とみなしており、完全に互換性のないものは考慮に値するとみなされなかったため、TruffleRuby がかなり高速になるかどうかはあまり問題ではありませんでした。

この時点で、私がこの問題で何をしようとしているのかがわかっていただければ幸いです。 私の経験に基づく結論は、自分のプロジェクトを何かの代替実装として位置付けるのは失敗だということです。 あなたがどれだけ賢いかは関係ありません。 どれだけ頑張っても関係ありません。 問題は、代替実装を構築すると、正規実装の気まぐれに自分自身が影響されてしまうことです。 彼らはプロジェクトの方向性をコントロールしており、あなたにできることは、それに追いつくように努めることだけです。 従来のインタープリタ型言語の JIT 実装の場合、インタプリタで新しい機能を実装する方がはるかに高速であるため、少し奇妙なダイナミクスが存在します。 正規実装の実装者は、あなたを、彼らが追い抜こうとしている競争相手とみなすかもしれません。 上り坂でアイススケートをしようとして行き詰まっているかもしれません。

ほぼ 4 年前、Shopify のサポートを受けて、2 人の熱心な同僚と私は、さらに別の Ruby JIT である YJIT を構築するプロジェクトを開始しました。 違いは、YJIT を代替実装としてではなく CRuby 自体の内部に直接構築するという重要な選択をしたことです。 これには多くの設計上のトレードオフが伴いましたが、重要なことに、YJIT は最初からすべての CRuby 機能と 100% 互換性を持つことができました。 YJIT は現在「公式」Ruby JIT であり、特に Shopify、Discourse、GitHub にデプロイされています。 今日 github.com または Shopify ストアにアクセスしたことがある方は、YJIT とやり取りしたことになります。 これまでのところ、私たちは他のどの Ruby JIT コンパイラーよりも多くの成功を収めてきましたが、これを達成するには互換性が鍵でした。

これを読んで、この投稿の重要な教訓は「彼らに勝てないなら、彼らに加わろう」という古い格言に従っていると思うかもしれません。 ある意味、そうなのだと思います。 私が言いたいのは、何かの代替ではあるがより優れた実装として自分自身を位置づけようとしてプロジェクトを開始すると、常に後追いをして、その影の中で生きている状況に陥る可能性が高いということです。正規の実装。 正規プロジェクトは進化し続けるため、自分のプロジェクトがどこに向かっているのかについて、限られた決定権を持って従うしかありません。 それは面白くありません。 代わりに正規の実装に参加することを試みた方が幸運かもしれません。 ただし、それは答えの一部にすぎません。

Ruby スペースには、型推論を使用して静的にコンパイルされる Ruby に似た言語である Crystal もあります。 この言語は意図的に Ruby と互換性がなく、Ruby から分岐することを選択しましたが、依然として限定的な成功しか得ていません。 広い視野が得られるので面白いと思います。 Ruby 主義者は Crystal を好みません。それは、Crystal はほぼ Ruby ですが、完全ではないからです。 構文的には Ruby に似ていますが、多くの微妙な違いがあり、実際には互換性がありません。 これは人々を混乱させるだけであり、期待を裏切るものです。 Crystal はおそらく、最初から Ruby に似ていると自社を売り込んでいなかったらもっと幸運だっただろう。

ピーター・ティールはこんな言葉を残しています。 「競争は敗者の為にある」。 彼の主な主張は、必要がないのに競争を強いられるような立場に自分を置くべきではないということだ。 若いプログラマーへの私のアドバイスは、たとえば、独自のプログラミング言語を作成しようと考えている場合は、Python のサブセットや、表面的に既存の言語に非常に近いものを作成しようとしないことです。 自分のことは自分でやれ。 そうすることで、言語が別の実装のパフォーマンス、機能セット、ライブラリ エコシステムに一致する必要があるという期待に縛られることなく、自分のペースで自分の方向にシステムを進化させることができます。

いくつかの注意事項を述べて終わります。 上で述べたことは、言語またはシステムの正規実装が存在する状況に当てはまります。 オープンスタンダードがある分野では適用されません。 たとえば、独自の JSON パーサーを実装したい場合は、明確に定義された仕様があり、比較的小規模で、それほど急速には進化しません。 これは、あなたなら十分に達成できることです。 また、ブラウザベースの JavaScript 実装が複数存在する状況もあります。 これが可能なのは、JS 仕様を管理する外部標準団体があり、JS 標準に取り組んでいる人々が、JIT コンパイルされた実装がパフォーマンスにとって重要であることを理解しており、それに応じて言語の進化を導いているためです。 彼らは、できるだけ早く多くの新機能を追加することに取り組んでいません。