言語は誰でも書ける:世界を救うにはコンパイラが必要だ

Table of Contents

言語は誰でも書ける:世界を救うにはコンパイラが必要だ

意見:幸せの秘訣はこれだ。「Cは言語ではない」という最近の騒動に興奮しすぎないこと。

まともなプログラマーなら、C言語が他の言語と同様に、アセンブラマクロの美化されたライブラリであることは、その誕生以来ずっと分かっています。心配する必要はありません。オペレーティングシステムが古いC言語の遺伝子に侵され、新しくてクールなRustやSwiftが機能しなくなるなんて、どうでもいいでしょう?もしあなたのコードがOSとのやり取りによって制限されているなら、カーネルを書いた方がいいでしょう。

あなたの感情と知性のエネルギーを注ぎ込むべき場所はただ一つ、コンパイラーだけです。彼らはかつて世界を救い、そして今にもまた世界を救おうとしています。

若いプログラマの多くにとって、コンパイラはデータの神々との、やや神秘的なインターフェースだ。うまくいけば、完了メッセージがターミナルウィンドウに流れ、まるで大祭司が信者に祝福を与えるかのようだ。もし間違ったことをすれば、コンパイラは火と硫黄を浴びせかけ、あなたは悔い改めなければならない。審判の日が来たら、あなたの実行ファイルが報酬となる。

ベテランは、コンパイラ技術が単純なgo/no-goコード解析よりもはるかに複雑であることを知っています。グレース・ホッパーがコンパイラを生み出してから70余年、プロセッサ設計におけるあらゆるマイルストーンは、コンパイラの進歩、あるいはその不在によって、祝福され、あるいは呪われてきました。Itaniumが消滅したのは、Intelがコンパイラを高速化できなかったからです。Armが繁栄したのは、そのコンパイラがそのパフォーマンスを実現したからです。

市場を統合できるのはコンパイラだけです。C言語のコンパイラ技術が複数のプラットフォームに容易に移植できなければ、C言語は脚注程度のものしか残らないでしょう。逆に、コンパイラは市場を分断させることもあります。1980年代、複数のモノリシックCコンパイラが移植を困難にすることで製品を特定のプラットフォームに縛り付けようとしていた時代を思い出してください。それらのコンパイラはそれほど優れておらず、互換性も低く、開発は必要以上に遅く、困難を極めました。

GNU

GCCへのコード貢献はもはやFSFに割り当てる必要はないとコンパイラ団体は述べている

続きを読む

GCCがその環境にもたらした変化は、言葉では言い表せないほどです。コンパイラは、フロントエンド、オプティマイザ、バックエンドの3つのコンポーネントに分けられます。フロントエンドはコードを受け取り、オプティマイザがルールに従って配置できる形式に変換します。バックエンドは、その出力をターゲットシステムに適したオブジェクト形式に変換します。GCCはこの構造を解放したため、新しい言語を書きたいときは、フロントエンドのことだけを考えれば済みます。新しいターゲット命令セットは、バックエンドだけで済みます。特定のキャッシュ構造は、オプティマイザに任せます。その恩恵は、すべての人に共有されるのです。

コンパイラの真の魔法はそこにあります。世界で最も思慮深く設計された言語を持っていても、コンパイラが遅いコードを生成するなら、誰も気にしません。GCCなら、他の誰もが持っているパーツキットと同じものを手に入れ、自分の言語やプロセッサを特別なものにすることに集中できます。GCCがGNU CコンパイラではなくGNUコンパイラコレクションになったとき、コンパイラの経済性と範囲は飛躍的に向上し、システムイノベーションも軌道に乗りました。

  • データプライバシーの第一歩は、問題があることを認めることです、Google
  • ファイルエクスプローラーの失態:マイクロソフトの複雑な動機が垣間見える
  • 1140億個のトランジスタ、大したことはない。AppleのM1 Ultraが警鐘を鳴らす
  • 企業のITは、シナリオのない戦場にいる

その後、LLVMはさらに一歩進み、コンパイラ技術をライブラリ群に分割しました。これにより、データ構造の最適な管理や複雑なコマンドの解析など、コンパイラが得意とする機能の一部を、データベースやブラウザ、そしてあらゆる種類のアプリケーションに追加できるようになりました。確かに言語はクールですが、完全なアーキテクチャのコンポーネントモデルの方がクールです。魔法のボトルが欲しいですか、それとも車輪の再発明をしたいですか?

これは歴史ではない。未来だ。インテルの言うことは無視していい。ムーアの法則は終わった。単一プログラムのパフォーマンスは限界に達した。業界はアクセラレータ、異種マルチコア、複雑なメモリ、超並列コンセプトを中心としたタスク特化型設計へと移行しつつある。

これらは全て異なっており、ある言語向けに書いたコードは別の言語には移植できず、ましてや次のバージョンにも移植できません。これらはドメイン特化型のアーキテクチャであり、ドメイン特化言語を必要とします。アクセラレータメーカーがそれを開発し、ユーザーは与えられたものを受け入れるだけです。まるで1980年代のCコンパイラの地獄絵図のようです。ただ今回は、すべての言語が同じような状況になっています。

C-spittersが「君のコンピュータはPDP-11の強化版じゃない」と言うのは構わない。しかし、彼らのコンピュータは、統一されたメモリ空間と均質なマシンコードを備えたフォン・ノイマンやハーバードでさえ、ますます劣っている。彼らの言語的前提は間違っており、しかも悪化の一途を辿っている。

幸いなことに、超並列システムには多くの共通点があることが分かってきています。メモリ階層、タイリング、セキュリティ、電力管理を管理する制御CPUは、TensorFlowを高速化する場合でも5Gを高速化する場合でも、同じ役割を果たします。

これらを合理的に抽象化できれば、共通の方法で処理できます。実際、LLVMの新たな発展形であるMulti Level Intermediate Representation(MLIR)はまさにそれを実現するプロジェクトであり、オープンソースコンパイルの実証済みの奇跡を、必要な場所に直接戻すものです。ハードウェアの命令セットについても、これもオープンソースで、高度なモジュール化と豊富な開発エコシステムがあれば素晴らしいでしょう。

RISC-V はいかがですか?RISC-V と LLVM の相乗効果は最初から存在していました。

これらはまだほとんどがこれからですが、歴史の力をすべて受け継いだ前進の道であり、業界にとって他のどの選択肢よりもはるかに大きな経済的・技術的可能性を秘めています。ぜひとも、言葉遊びを楽しんでください。楽しくて無害なLARPeryです。しかし、真の楽しみは未来を組み立てることです。®

Discover More