LLVMとの離婚申請

 (github.com/ziglang)
2 ポイント 投稿者 GN⁺ 2023-07-01 | 2件のコメント | WhatsAppで共有
  • Zigプロジェクトは、メインのzig実行ファイルからLLVM、Clang、LLDライブラリへの依存を完全に取り除くことを目標としている
  • 残っている作業は、LLDの削除、LLVM API呼び出しの削除、C/x86/wasm/aarch64バックエンドの進展、Clang依存のサブコマンドとプリプロセッサ使用の削除、zig arの代替実装などに分かれる
  • LLVMバックエンドはすでに.bcファイルを出力できるが、Zigコンパイラは.bcをオブジェクトファイルへコンパイルする機能を持たなくなり、この用途ではClangの別途インストールが必要になる
  • 期待される効果として、ソースビルドとブートストラップの簡素化、LinuxディストリビューションやHomebrewにおけるLLVM/Clang/LLD関連の問題回避、バイナリサイズの約150 MiB → 5 MiBへの削減が挙げられている
  • Zigが独自の最適化パスを実装し、alive2のような研究プロジェクトやIntel、ARM、RISC-Vのチップメーカーからの直接的な貢献を呼び込めるという方向性を打ち出している

Zig実行ファイルから取り除こうとしている依存関係

  • このイシューの目標は、ZigプロジェクトからLLVM、Clang、LLDライブラリを完全に取り除くこと
  • 残っている接続点は、LLD、LLVM、Clang、zig arの領域に整理される

LLD関連の残作業

LLVM関連の残作業

Clang関連の残作業

zig arと.bcファイル処理の制約

  • zig ar: a drop-in llvm-ar replacement #9828: zig arをllvm-arの代替品にする作業が残っている
  • LLVMバックエンドはすでに.bcファイルを出力できるが、Zigコンパイラは.bcファイルをオブジェクトファイルへコンパイルする機能を持たなくなる
  • このユースケースに対応するには、Clangを別途インストールする必要がある

依存関係の削除で期待される変化

  • Zig側のバグがすべてZigプロジェクトの責任範囲に収まる
  • コンパイラをソースからビルドしてブートストラップする過程が簡素化され、ホストシステムにはCコンパイラだけあればよくなる
  • LinuxディストリビューションやHomebrewのようなパッケージマネージャが、LLVM、Clang、LLDに関連して生じていた問題を扱わなくてよくなる
  • Zigコンパイラのバイナリサイズが約150 MiBから5 MiBへ縮小する
  • コンパイル速度が桁違いに速くなる可能性がある
  • Zigが独自の最適化パスを実装し、コンピューティングの最先端を押し上げられる
  • alive2のような研究プロジェクトを呼び込める
  • Intel、ARM、RISC-Vのチップメーカーのように、自社CPUでより良いマシンコードを望む利害関係者からの直接的な貢献を促せる

関連記事

2件のコメント

 
alstjr7375 2023-07-02

LLVM ほどの最適化やプラットフォーム対応は可能なのでしょうか..
 
GN⁺ 2023-07-01
Hacker Newsのコメント

  • Andrewはもともと非常に鋭い人物なので、目標として掲げられた以上、チームは最終的にやり遂げそうだと感じる
    ただ、LLVMまわりでZigが抱えている難しさをよく知らない立場から見ると、この決定はチームの力をZig本体ではなく、binutilsのような周辺ツールへ振り向けるようにも見える
    タイトルだけ見たときはコンパイラを捨てるのかと思ったし、ZigのようなプロジェクトならLLVMを維持して得られるものも多そうに思える
    それでも、LLVM内の多くのコードをC++の代わりにZigで書き直す構想はかなりクールで野心的だ。LLVMを作ったLattnerの試みに匹敵するほど野心的だとも言える
    ただし、偶然に二次時間計算量になってしまうコードは、ZigもLLVMと同じくらい人気で有用になれば避けにくいだろう

    • 昔、NASAの非公式なプロジェクト管理文書らしき文章で見た一節を思い出した
      「宇宙ミッションが既存の打ち上げ機を再利用しないなら、そのプロジェクトは打ち上げ機開発プロジェクトとなり、ミッションの中核だと思っていた残りの部分はすべて副次的な仕事になる」という趣旨だった
      さらに覚えているのは、「既存の打ち上げ機に合わせて妥協する代わりに、特定のミッション向けの打ち上げ機を作ればもっと安く効率的になると考えるかもしれないが」という前提が添えられていたことだ
    • Swiftの成功についての最近のChris Lattnerのインタビューを思い出す。彼は、大規模なObjective-Cプロジェクトで何も書き直さずにSwiftを混在させて使い始められたことを成功要因と見ていた
      Rustの成功の一部もC/C++との似た互換性の上に成り立っている
      Zigが同様の能力なしに成功するのは想像しにくく、だからこのマイルストーンをそのまま押し進めないでほしい
    • LLVMとはかなり事情が違う。少なくともAppleがそのプロジェクトを引き取った文脈では、選択肢はあまりなかった
      GCCがAppleの望むこと、あるいは必要としていたことを許可または実装しようとしなかったからだ
    • 「目標として宣言された」というわけではない。まだ受理されていない提案だ
    • binutilsは、移植性のある形でバイナリコード形式を扱う汎用ツール群に近く、コンパイラはその半分、特にレガシーまで必要としているわけではない
      TCCのようにもっと絞り込めば、大半は複数アーキテクチャ向けのコード生成になるはずだ

  • ここには二つの問題がある。一つはコード生成で、もう一つはブートストラップだ
    経験上、コンパイラの最適化パスは書きやすくて楽しい。レジスタ割り当てやSSA形式を理解するには論文を読む必要があるが、IRをさまざまな最適化パスに流して徐々に磨いていくコードは楽しく書ける
    LLVMなしでも高品質な最適化パスは作れる。しかしIRを機械語へ線形化する段階は、「mov [eax+8*ebx], 123」命令をx86-32/64がエンコードするあらゆる方法が好きでもない限り、退屈で地味な作業だ
    バイナリサイズを最適化するなら、あるプラットフォームで「push eax; push eax; push eax」が「add rsp,12」より短いか測りたいだろうか？ これはx86だけの話で、ほとんどの開発者には重要でない非x86アーキテクチャまで掛け合わせると、話ははるかに大きくなる
    あまり使われないアーキテクチャのコード生成器では、大きなバグが何年も見つからない可能性も非常に高い
    二つ目はブートストラップだ。Zigで書かれたZigコンパイラを何でコンパイルするのか？ たとえばCで書いた非最適化の最小ZigコンパイラでZigコンパイラをコンパイルすることはできる
    しかし非最適化なら、その後でもう一度、最適化されたZigコンパイラでZigコンパイラを再コンパイルしなければならない。解けない問題ではないが、長く複雑なビルド過程は潜在的な貢献者を遠ざける危険がある

    • この記事はブートストラップ問題を扱っているようだ: https://ziglang.org/news/goodbye-cpp/
    • ZigはすでにCバックエンドでブートストラップしているので、二つ目の問題は問題ではない

  • ZigがC、ひょっとするとC++までコンパイルできるとあれだけ宣伝しておいて、今度はLLVMを完全に外すというのはかなり過激に見える
    よほど多くの人がサポートに参加しない限り、LLVMレベルのプラットフォーム対応に近づける可能性も非常に低そうだ
    望む人向けに独自バックエンドを追加する計画は理解できるが、LLVMをそのまま取り除くのは性急に見える

    • すでに作業が始まっているなら性急かもしれないが、issue trackerの「accepted」ラベルが付いていない他の提案と同様に、今は議論と対案を求めている段階にすぎない
      今はチームがフィードバックを集め、影響を受けるユースケースを学び、実現可能性を見極めている段階なので、性急というよりはむしろその反対に近いと思う
    • リンク先のissue本文を読むと、LLVMバックエンドを完全になくすわけではない。メインバイナリから分離するだけで、システムにLLVMがインストールされていれば引き続き簡単にバックエンドとして使える
      一般的なケースでは必要ですらない100MB超のLLVMコピーをバンドルしなければならないのは少し奇妙なので、理にかなっている。開発者ならどうせインストール済みのことも多いだろう
      ただし、インストールされたZigがシステムのLLVMバージョンと正しく動作すると保証するのは難しいかもしれない。様子を見る必要がある
    • 依然としてLLVMビットコードは出力するが、もはやLLVMライブラリには依存しなくなる
      https://github.com/ziglang/zig/issues/13265
    • 私もまさにそう受け取った
      最近Zigをもう少し読んで、システムパッケージと格闘せずにLLVMでC++を簡単にコンパイルする手段としても試してみた。C/C++からZigへ移れるという点が大きなセールスポイントだった
      かなり唐突で予想外だ。プロジェクトにとって合っているのか間違っているのかは分からないが、私の立場からすると本当に脈絡なく感じる
    • RustプロジェクトでZigをC++コンパイラとして使っている。GitHub Actionsでクロスコンパイルするいちばん苦痛の少ない方法だったからだ

  • 一方で、依存関係を減らそうとする几帳面な姿勢には敬意を払うが、その代償はかなり深刻に見える
    C++互換性の喪失は、私の周囲のZigファンが最もよく挙げていた利点を事実上なくすことになる
    性能低下も、一時的だとしても、彼らがあわせて挙げていたもう一つの重要点だ

    • 反応の大半はこの提案に反対しているように見える
      軽く読んでいる人向けに言うと、これは決定事項ではなく提案だ

  • 約4年間、組み込みプロジェクトとライブラリをすべてZigで書いてきたのに、今後は複数のtier 1対応アーキテクチャが単に外されるということか？
    言語はあちらのものなので好きにすればいいが、そうするならブランディングもそれに合わせて調整してほしい

    • 本当に外されるのか？
      おそらくtier 1対応は2つのカテゴリに分かれることになる。内蔵のtier 1対応と、オプションのLLVMバックエンドによるtier 1対応だ
      すでにあるアーキテクチャがtier 1対応なら、LLVMバックエンドをオプション依存に変えたからといってその対応が失われる理由はないように見える
      Andrewが提案で書いていたように、このやり方はむしろより珍しいアーキテクチャをうまくサポートする道になるかもしれない。面白いプロセッサアーキテクチャ向けのZigバックエンドなら喜んで取り組むが、LLVMには絶対に貢献しない。C++で作業するのは趣味でやるようなことではない
    • LLVMがやっていることをすべて独自方式で再実装してLLVMを外すということか？
      その利点は何だ？ 資源の浪費ではないのか？
    • Zigが1.0前だというのは秘密でもない。この責任を全面的にあちらに負わせるのは難しいが、それでもかなり過激な提案に見える
    • まだ提案段階にすぎない。GitHub issueも主に賛否やユースケースなどを投稿するための場所で、Acceptedではない
    • これはまだ提案なので、十分多くの人が意見を出せば、すでに多くの人がそうしているように、コアチームも方針を調整すると思う

  • DLangにはコンパイラが3つある
    gdcはGnuコンパイラコレクションのバックエンドベースで、ldcはLLVMバックエンドベース、dmdは私がZortech/Symantec/Digital Mars向けに書いたx86コードジェネレータベースだ
    それぞれ長所・短所と対象が異なるが、対応しているD言語は同じだ
    全体としてユーザーは選択肢を好み、中には2つ以上を併用する人もいる

    • 興味深いアプローチの違いがある。Dは完全に別個のコンパイラを持っているように見えるが、ZigはインストールされていればメインのZigコンパイラがLLVMをバックエンドとしてサポートする方向のようだ
      それが正しいなら、Zigのアプローチのほうが好みだ
    • 複数のコンパイラを持つ別の言語としてCommon Lispがある。商用もあるが大半は無料で、プロダクション対応のコンパイラが10個前後ある
      そのおかげで開発中は最速のコンパイラを使い、最終リリースでは最速のランタイムや最小のメモリ使用量を持つコンパイラを使えるので非常に便利だ
      また、すべてのコンパイラが従う言語仕様があれば、言語が安定していて下の層で突然壊れないという保証にもなる
      もちろん、Zigのようにまだ好きなように変更して、言語をより一貫性があり、きれいで、強力にできる言語にも利点はある。最近はこうした安定性をずっと高く評価するようになった。開発ツールを追いかけ続ける代わりに、ユーザーに実質的な価値を生むことに集中できるからだ
    • 上級ユーザーに選択肢があるのは利点だが、選ばなければならないこと自体は大きな欠点だと思う
    • ユーザーが選択肢を好むのは分かるが、Zigが長期的に広い採用を目指すなら、DLangは良い先例ではないと思う

  • Zigが面白かった主な理由の1つは、C/C++コンパイラの代替としてそのまま差し込めたことだった
    Windowsでは、他のどんな代替よりもZigをC/C++コンパイラとしてインストールしやすいと友人たちは言っていた
    この提案が受け入れられたら、個人的にはZigの人気はHareや他の極端にニッチな言語並みに落ちると思う
    同僚にZigを一度でも試してもらうには、Uberが本番環境で使っているという記事まで送らなければならなかった。既存プロジェクトに即時の価値がなければ、同僚たちは二度考えもしなかっただろう
    それでも提案の背景は理解できる。LLVMのコンパイル時間はひどく感じられることがあるし、独自のバイトコードがあれば面白い最適化手法も実装できる。LLVMのバグを扱うのは実質的に手を出しにくい作業で、Juliaエコシステムでもそういうことを見てきた
    私の提案に意味があるなら、Zigは1) デバッグビルドでは高速ビルドと高速デバッグのためにカスタムバイトコードを使い、2) リリースビルドでは高速なランタイム性能のためにLLVMを使うのがよいと思う
    C/C++クロスコンパイル対応を維持しつつ1)を実現できるなら、たとえばその部分だけLLVMに渡すなら、追加のバックエンドコードを保守しなければならないというトレードオフはあるが、最良の折衷案かもしれない

    • JuliaエコシステムでLLVMのバグ対応をしている人間の1人として言うと、その通りだ
      高水準のJuliaコンパイラ作業とは別のスキルが必要で、バグ修正をアップストリームにマージするのに時間がかかることもある
      だが実際には、我々はアップストリームとかなり良好で生産的な関係を維持しており、LLVMをなくすと決めていたら、プロジェクトで達成できたことはずっと少なかっただろう
      特にGPU対応やHPC対応、たとえばPPCはLLVMに依存している
      なので我々は、Juliaを自分たちのパッチセット/フォークに合わせてビルドすべきだという立場を取り、そのパッチを使っていないJuliaビルドで発生したバグには時間を割かない。特にディストリビューションのビルドでよく起きる

  • 他の言語の非LLVMバックエンド開発を見てきた立場からすると、リンク先の提案からは傲慢さが強く感じられる
    書いたのがあの人でなければ、Zig初心者が適当に書いたGitHub issueだと思って流していたはずだ
    必要な作業量を過小評価し、LLVMに注がれてきたすべての作業を暗に見下しつつ、「当然うちならもっと安く、速く、良くできる」という自信とマッチョさが文章の端々からにじんでいる。失望した
    これまでAndrewの仕事は本当に尊敬してきたので、急いで、あるいは即興で書いたせいでそう読めてしまうことに気づかなかったのだと善意に解釈したい
    しかしこの文章は信頼を与えず、提案そのものをもっと開かれた気持ちで見る助けにもならない

    • LLVMバックエンドのことはまったく分からないが、ユーザーの問題を100%解決しようとするライブラリは、より最適化された代替と比べて扱いにくく遅くなりがちだ
      Webpackとesbuildがその例だ

  • LLVMなしで何かを作る適切なタイミングは数年前だった。だが今C++機能を外せば、Zigの終わりになる可能性が高い
    段階的に削る代わりに、Zigで独自のC++コンパイラを書く計画を発表しなかったのは驚きだ

    • C++パーサーを書くだけでも巨大なプロジェクトだ
      18歳の誕生日に始めた個人がC++コンパイラを書けるのかすら確信がない。動くコンパイラを作るだけの残りの人生の時間が十分にあるかどうかも分からない

  • Zigは世界の新しいCになりたいのであって、世界の新しいC++になりたいわけではあまりない
    この提案でも Cクロスコンパイル は引き続きサポートされることが見て取れる
    この選択は正しいかもしれない。Cは現在も組み込みの世界で広く使われており、その領域ではLLVMはあまり優れていない
    私がZigなら、あらゆるマイクロコントローラを対象にしたいと思うだろうし、それを達成する現実的な道はこれしかない