見出し画像

CPUの仕組みがようやく分かりました（Casey Muratoriと共に）

AGIに仕事を奪われたい

76,130 文字

JavaScript開発者として知られている私ですが、実はハードウェアにもかなり詳しく、CPUからGPUまで、さらにはLTTのLukeとの交流など、ハードウェアにも深い関心を持っています。ただし、それは私が正確な知識を持っているという意味ではありません。数ヶ月前にx86ワーキンググループについて動画を作った時に、それを痛感しました。
ありがたいことに、私の動画を見てくれている素晴らしい人々の中には、私を正してくれる人もいます。その中にはCasey Muratoriもいました。彼はゲーム開発、ハードウェア、エンコーディングなど、あらゆる分野での伝説的な存在です。彼は非常に丁寧に、私の動画で述べたことのほとんどが間違っていることを指摘してくれました。彼自身はそうは言いませんが、私はそう言います。
私はソフトウェア開発者の視点からこれらの事を説明しようとしたため、その部分については良かったのですが、ハードウェアの実際の動作について推測を始めたとたん、すぐに破綻してしまいました。幸いなことに、Caseyは親切にもストリームに参加してくれて、私の誤解を明確にし、非常に興味深い指摘をしてくれました。
特に彼が指摘したのは、私が間違えた情報の多くは、実はアクセス可能な情報ではないということでした。AMDがこれらの仕組みについて公開しているわけではなく、ハードウェア企業はこのようなデータを共有していないのです。そのため、私たちは自分たちでリバースエンジニアリングして理解する必要があります。
プロセッサの仕組みを本当に理解したい場合や、ウェブ開発者としてこれらが日々の仕事にどう影響するのか知りたい場合、この内容は非常に有用だと思います。申し訳ないことに、動画の長さを見てしまいましたが...できる限り痛みを和らげ、スポンサー広告も入れないようにします。この会話全体は価値があり、再度Caseyには感謝しています。
Caseyの話に興味を持った方は、computerenhance.comで彼のニュースレターをチェックしてみてください。これらのトピックについての素晴らしい内容が満載です。彼自身も最後にその宣伝をしています。
それでは、専門家の話を聞いてみましょう。
やあやあ、調子はどう？自己紹介をするなら、どんな風に説明する？
私はYouTuberの多くよりも年上かもしれません。技術系の分野では年配の人もいますが。私は長い間プログラミングをしてきました。ゲーム業界では1994年か1995年くらいから携わっています。ほとんどの期間は実際のゲームエンジン技術に取り組んできました。RAD Game Toolsという会社で働いていましたが、そこではゲームで使用されるSDKを多く開発していました。
例えば、私たちが開発したビデオコーデックは、多くの人がゲームを起動する時に目にするロゴで知られています。キャラクターアニメーションソフトウェアの開発にも携わりました。
現在は、教育コンテンツの制作に取り組んでいます。ハードウェアが実際に何をしているのか、ソフトウェアがハードウェアとどのようにインターフェースしているのかなど、より低レベルのプログラミングについて学びたい人向けの内容です。それが今日のストリームにつながっていると思います。
とても興味深いですね。私の方から言わせてもらうと、CPUアーキテクチャについて軽く触れた動画を作り、アーキテクチャの違いについて十分な知識がないまま概要を説明しようとしました。コメント欄を見れば分かる通り、かなり間違いがありました。
Caseyは動画を批判するのではなく、これらをより良く理解できるよう手を差し伸べてくれました。ご存知の通り、私は間違いを指摘されることが大好きです。それは自分がより賢くなり、より理解を深められる機会だからです。
私は常にアーキテクチャについてのオタクを自認してきました。それは私が得意だという意味ではなく、単にとても興味を持っているという意味です。例えば、Casey、あなたはAnandTechのAnand Laiの経歴をご存じですか？
彼のサイトは常に読んでいましたし、特に彼が始めた頃や、Ian Cutressが引き継いでからもよく読んでいました。残念ながら今は存在しませんが。ただ、彼の経歴については詳しくありません。
私が言及しようとしたのは、iPhone 5Sの64ビットアーキテクチャに関する記事を書いた後、Appleが彼を引き抜き、その後約10年間Appleのストレージチップセットを率いているという話です。
それは知りませんでした。
彼のおかげで、最初のMacBook 12インチのような超薄型モデルに1テラバイトのSSDを搭載することができたんです。
へぇ、彼のおかげだったんですね。
彼は私のヒーローの一人です。このように私はこういった分野に詳しいですが、先ほど言った通り、それは得意だという意味ではありません。だからこそ、より多くを学べることをとても楽しみにしています。
それに関連して付け加えさせてください。これらの事について正しい情報を得るのは本当に難しいのです。私が教育コンテンツを制作する中で、より困難を感じるようになりました。正確な情報を確認しようとするときに、ハードウェアの関係者からその仕組みについて話を聞くのは極めて困難です。
彼らは非常に秘密主義で、もちろんそれなりの理由があるはずです。特許争いが起こることもありますし、開発には長い時間がかかるので競合に知られたくないという事情もあります。secretiveな文化には十分な理由があるのでしょう。
しかし、私が非常に苛立たしく感じるのは、これらの事について正確な情報を得るのが難しいということです。ソフトウェアの世界では、例えばReact.jsの動作について不確かな点があれば、資格があれば直接ソースコードを見ることができます。推測する必要はないのです。
しかしハードウェアの世界ではそうはいきません。ソースを見ることはできません。Zen 4のVLSIデザインソースを見ることはできません。すべてがNDAの下にあり、質問しても答えてもらえません。
そのため、人々が誤解を持っていたり間違いを犯したりするのは理解できることだと思います。ソフトウェアであれば期待できるような情報が、ハードウェアでは得られないのです。
その点について、これほど明確で簡潔な説明を聞いたことがありません。Intel ArcのGPUが登場した時、彼らが非常にオープンに情報を公開し、チップの設計者と直接話ができることが画期的だと考えられていた話や、先ほど話したAnandがAppleのCycloneアーキテクチャをリバースエンジニアリングした際、Appleが法的措置で情報を隠そうとするのではなく、彼の才能を認めてチームに迎え入れた話など、すべてがあなたの指摘する点に通じています。
これらのハードウェア企業は一般的にこういった情報を秘密にしています。私はオープンソースの信奉者として、ソフトウェアエンジニアリングだけでなく、私の行うすべての作業について可能な限りオープンにしようとしています。コンテンツ制作のプロセスを効率化するために使用するツールは、すべてオープンソースで公開するか、使用方法を詳細に文書化しています。
私にとって興奮するのは個々のピースではなく、それらを使って何ができるかということです。より多くの人々がこれらのピースを理解し、アクセスできれば、より面白いことができるはずです。もちろんハードウェアには非常に高い参入障壁がありますが、それでもこれほど参入が難しいのは残念です。
そうですね。ビジネス上の現実から考えると難しいかもしれませんが、ハードウェア企業にもう少しオープンになってほしいと思います。少なくともソフトウェア側については。
例を挙げると、NVIDIAで働く複数の知人がいますが、誰も4090 GPUのダイ上にどこにFMA（Fused Multiply-Add）コアが配置されているのか教えてくれません。シンプルな質問なのですが、そういった情報について話すことは許可されていないのです。
配置を推測することはできますが、誰も正確には知りません。皮肉なことに、そういった情報は別の企業のリバースエンジニアの方が詳しかったりします。フォトン放射顕微鏡を使用してマイクロベンチマークを行い、どの部分が発光するかを観察して、CUDAコアのクラスターはここにあるはずだというように特定しているのです。
つまり、コアのレイアウトを知りたい場合、インターネット上で誰かが推測して作成したダイショットの注釈を見るしかありません。それが現状なのです。
JavaScriptの難読化解除よりもずっとひどいですね。
そうですね。
私たちの分野で似たような経験があるのは、ほんの一握りの企業だけです。例えばSonyは、JavaScriptやReactを使って本当にクールなことをしています。PlayStation 5の全オペレーティングシステムがReactベースだということをご存知でしたか？
まさか！そのクロスプラットフォームのこと？
はい、ホーム画面からボタンを押したときに表示されるバー、ストアまで、すべてがReactネイティブアプリです。そのアーキテクチャは実際にとても面白いものです。友人から聞いて詳しく知っているのですが、ここで話せる範囲を超えると彼らが困るので控えめにしておきます。
今はjailbreak（脱獄）コミュニティがこれらの情報を見つけ出すのを待って、その情報源を使って意味のある形で話ができるようになるのを待っています。こういうのは本当に嫌いです。単に技術的な詳細についてオタク的に語り合いたいだけなのに。
私もそう思います。
では、その流れで基本的なCPUアーキテクチャについて話しましょう。先ほど言及した注意点として、私たちができる限りの情報を提供しますが、望むような詳細は得られないということです。なぜハードウェア設計者たちがストリームに来て話をしないのか、その理由が分かりますよね。彼らは単に...そうしたがらないのです。
そして信じてください、私は試みましたが、彼らは本当にそうしたがらないのです。
さて、私はあなたの動画を見て、いくつかのスクリーンキャプチャを取りました。議論された内容を思い出すためです。その一つがALU（Arithmetic Logic Unit：演算論理装置）の概念についてでした。
ALUという用語は、数十年前からチップアーキテクチャの歴史の中で使用されてきました。基本的な計算を行うものを指します。正確な歴史は分かりませんが、Arithmetic Logic Unit（演算論理装置）と呼ばれる理由は、典型的にこれらが複数のことを行うためです。
時にはExecutin Unit（実行装置）と呼ばれることもありますが、これらはシリコン上に配置された多くのトランジスタが配線で接続されたものです。この回路を多目的に使用する方法があるのです。これはソフトウェアでも馴染みのある概念です。パラメータを受け取って複数のことを行う関数のようなものです。
ALUも同様です。あなたの動画では、CPUには多くのALUがあり、x86には15,000から3,684の命令があり、ARMには230程度しかないという話をしていました。この会話の部分について、まず最初に説明したいことがあります。
ソフトウェア側で考える命令、つまり低レベルのプログラマーがドキュメントで見るような命令は、CPUが実際に行うことだと考えられています。これは正しいです。これらの命令がCPUに送られ、アセンブリ言語で書いていても、それらはCPUが取り込んでデコードし、実際に実行する何かに変換するバイナリデータになります。しかし重要なのは、これらの命令がALUに直接マッピングされないということです。
つまり、1,500の命令があるからといって、1,500のALUがあるわけではありません。代わりに、比較的少数のALU（通常20程度）があり、それぞれのALUは相当数の基本的な操作を実行できるように設計されています。これらをマイクロ操作（micro-operations）と呼び、命令とは区別します。
CPUに送る命令は、基本的にこれらのALUに実行させたいマイクロ操作のシーケンスを指定しているのです。そのため、Intel x64アーキテクチャに1,500以上の命令があるということは、ALUの数については何も教えてくれません。
具体例を挙げましょう。これはブロック図で、後であなたの動画で出てきたx86は死ぬべきだというブログ記事でも触れられていました。繰り返しますが、間違った情報は非常に簡単に広がります。そのブログ記事のほとんどは基本的に正しくありませんでした。マイクロアーキテクチャについて事前に知識がない人がそれを読んで正しいと思い込んでしまうと、それが頭に残ってしまいます。だからこそ、この分野で間違いが起こりやすいのです。
これはAMDのスライドプレゼンテーションから取られたブロック図です。AMDはAppleなどと比べると、チップで何が起きているかについてより開放的です。ブロック図を作成し、プレゼンテーションで目立つように表示しています。
このマウスカーソルで示している行に注目してください。これらがZen 4コアの実行ユニット、つまりALUです。数えてみると1、2、3、4、5、6、7、8、9、10、11、12、13、14と14個あります。先ほど20という数字を適当に挙げましたが、それは特定の誰かを指さないためです。しかし、この程度の数になります。1,500ではなく、20とか14とか8とかです。
これらは実行する処理の種類によってラベル付けされています。AGUはアドレス生成ユニット、ALUは演算論理ユニット、BRは分岐用です。こちらはチップの浮動小数点側、実際にはベクター側です。整数演算も行いますが、これはSIMD命令を実行する部分です。ここには乗算累積や加算器、データを格納する機能などがあります。
これらのチップを見ると、命令セットの命令数（15個であれ1,500個であれ15,000個であれ）と、この数との間には関係がないことが分かります。なぜなら、チップのこの上部の部分、通常CPU アーキテクチャではフロントエンドと呼ばれる部分が、それらの命令をこれらの実行ユニットで実行できるものに変換するからです。
申し訳ありませんが、私たちとは言うべきではありません。私はこれらについて知っているわけではなく、彼らが教えてくれることしか知りません。彼らがフロントエンドと呼ぶこの部分は、命令をマイクロ操作に変換します。だから先ほど、命令とマイクロ操作は異なると言いました。
あなたが書く命令はデコーダーを通過し、一連のマイクロ操作に変換されます。これらのマイクロ操作は、アウトオブオーダー実行やパイプライン処理など、他の多くの機能を持つチップ内のスケジューラーを通過します。可能な限り多くの処理を一度に実行しようとします。
これらのパイプラインを通過し、最終的にこれらの実行ユニットで実行されます。実際に起こることを考えると、ARMとx64、どちらが電力効率が良いかといった議論で、人々は混乱してしまいます。最初の部分、つまり命令の数に注目してしまうからです。
RISCとCISCの区別があったため、人々はそこに注目し、x64チップは命令が多いため内部がより複雑になるはずだと考えます。しかし実際にはそれほど真実ではありません。望むなら非常に小さなx86チップを作ることもできます。なぜなら、ダイ面積の大部分は命令をマイクロ操作に変換することには使われておらず、完全に別のことに使われているからです。
ただし、ここで注釈を付け加える必要があります。並列デコードは重要な要素で、そこにはリソースが使われます。しかしそれも命令の数とは関係なく、命令が可変長であるかどうかなど、他の要因に関係します。
このようなものを見ると、ARMとx64の違いを議論する際、ALUについて話す必要はないことが分かります。重要ではありませんし、どちらを見ても非常に似た数と種類のALUが見られるでしょう。
長く話しすぎないように...まず一つだけ見せたいものがあります。cardakというTwitterアカウントがあり、CPUの構造についての最善の推測ブロック図を管理しています。
ここでも同じように、異なるALUタイプやデータを格納できるものなどが見られます。先ほど指摘した部分と同じで、アドレス生成ユニット、ALU、分岐処理などがあります。これはZen 4の同じ図ですが、AMDのスライドプレゼンテーションよりも詳細な情報をコミュニティが推測して維持しているものです。
同じ人がM1のFirestormコア（ARMコア）についても同様の図を管理しています。見てみると、同じようなものが...実際にはここにはALU系の実行ユニットがより多くあります。しかし依然として同じオーダーの大きさです。
もしかしたらM1シリーズの方が多いのは、それが目的とする用途に対してより過剰なチップだからです。また、Rosettaのx86エミュレーションのような特殊な処理のために、多くの特別な機能を持っているとも聞いています。チップ上でどれだけの処理が行われ、どれだけが純粋にソフトウェアなのかは分かりませんが。
実際にそれについて話すことができます。動画で言及されていたので、それについての参考資料を用意してきました。
一般的に、実行ユニットが多い理由はそれではありません。より強力なチップを作りたかったからです。多額の費用を投じ、多くのダイ面積を割り当て、多くの実行ユニットを搭載し、それらに処理を供給しようとしたのです。
ARMの方が有利な点もありますが、それはここの上部に関係することで、後で話しましょう。とりあえず、これを手短に見せたかったのです。これら二つを見比べ、もう一度Zen 4に戻ってみても、大きな違いはありません。したがって、命令の数は、チップについて考える際に注目すべき点ではないのです。
では、その図に戻りましょう。質問があるとおっしゃっていましたね。
はい、とても役立つ背景説明をしていただき、議論の基礎となる理解が得られました。確認したいのですが、アセンブリの下にはマイクロタスク、つまりマイクロ操作という別の命令セットが存在し、加算命令のような単一の命令でも、開発者として見えない多くの異なる処理にマッピングされる可能性があるということですか？
はい、ただし、まったく見えないわけではありません。それについては後で話せると思います。しかし、そうですね。例えば加算命令は、CPUができる最も単純な処理の一つです。
ストリームを見ている人々のアセンブリ言語プログラミングの知識レベルは様々だと思いますが、レジスタ名という概念があります。加算を行う際、このレジスタをこのレジスタに加算するといった指定をします。x64でも、ARMでも同様です。
二つのレジスタを加算して、結果を（同じレジスタか、三項演算子を使用して別のレジスタに）格納する場合、これはほぼ確実に、少なくともx64では単一のマイクロ操作になります。一つの演算論理装置で一回の操作で実行できるほど単純だからです。
しかし、x64で許可されているように、レジスタをメモリ位置に加算する場合はどうでしょうか。つまり、そのメモリ位置の値をまだCPUコアに読み込んでおらず、キャッシュや他のメモリのどこかにある場合です。そのデータをフェッチして加算するように指示すると、単一のマイクロ操作にはなりません。
複数のマイクロ操作になります。なぜなら、そのフェッチを行い、最後に加算のための単一のマイクロ操作を実行する必要があるからです。実質的に、ロード命令と加算命令をコーディングしたことになり、パイプラインを通過する際に、特にここでデコードされる時に、複数のマイクロ操作に分解されます。
CPUの動作について理解し始めてきました。加算命令を使って、二つの生の値を与えた場合、一つの命令で一つのタスク、つまりマイクロ操作で実行できますが、値の一つがメモリアドレスの場合、アセンブリコードでは依然として一つの命令でも、アーキテクチャレベルでは異なるパイプラインを通って値を読み取り、それを持ってきてから正しいマイクロ操作に投入する、という意味で意味のある違いが生じるということですね。
その通りです。そして強調しておきたいのは、これは固定されているわけではなく、ARMやx64、あるいは他の何かの特徴でもないということです。CPUコアごとに変化します。Zen 4では複数のマイクロ操作かもしれませんが、Zen 5では突然一つのマイクロ操作になるかもしれません。分かりません。
それはハードウェアの設計方法と、その機能によって決まります。ハードウェアの設計者たちは常にこれらのことを考えています。達成したいことがあり、どのようなベンチマークで評価されるかも知っています。あなたや私のような人々がこのチップをどのように評価するか、ゲーマーはこれを買うのか、データセンターはこれを欲しがるのか、などを考えています。
すべてのベンチマークを考慮し、実行ユニットの内訳をどうするか、それぞれの種類をいくつ搭載するかを決定します。整数乗算器をいくつこのチップに搭載するかといったことです。より多くのダイ面積を使用したり、トレードオフを行って特定の機能を増やすこともできます。それは賢明な選択なのか、コストベネフィットに見合うのか、そういったことを考えているのです。
これは理解できました。CPUで質問『タスクにはいくつのマイクロ操作が必要か』に対する答えは複数あり得ます。なぜなら、Pコア（パワーコア）とEコア（効率コア）で異なるパイプラインを通る可能性があるからです。効率コアとパワーコアの文字はそういう意味だと思います。
ほとんどのプロセッサは、300ワットを常時消費しないようにするため、効率的にほとんどのタスクを実行できるコアと、CPUに負荷がかかる場合用のパワフルなコアを搭載する方向に向かっています。つまり、アセンブリがどのパイプラインを通るかによって、実際のマッピングが完全に異なる可能性があるということですね。
その通りです。劇的に異なる可能性があります。実際に先ほど示したEコアとPコアでは、マイクロ操作の数が異なっていました。Pコアはより強力な実行ユニットを持ち、特定の方法でより多くの処理を行える可能性があります。そのため、そこでマイクロ操作が実行される場合、処理全体の中でより多くを実行できるので、全体で2つのマイクロ操作で済みます。
一方、Eコアはその実行ユニットで1サイクルでそれほど多くの処理を行えないため、3つのステップに分ける必要があります。これは完全に正常なことです。リビジョン間でも非常に一般的です。M1からM2、M3、M4へ、あるいはZen 1からZen 2、Zen 3、Zen 4へと進化する中で、以前は高コストだったものが変化したり、時には逆に以前は1回で完了できていたものが複数回に分かれることもあります。なぜなら他の何かを最適化したかったけれど、その命令はそれほど重要ではなかったからです。
実際にそれが起きた例があります。また、あらゆるハードウェアについてオタクな私ですが、ベースモデルのM4 MacBook Proは、ベースモデルのM1 MacBook Proと比べて、重いオーディオ/ビデオソフトウェアでパフォーマンスが低下します。Logic Proで開けるトラック数が少なくなったりします。
これは、効率コアを増やしてパワーコアを減らすように移行したためです。というのも、このマシンで人々が本当に気に入っていた機能の一つがバッテリー寿命だったからです。彼らは効率コアはほとんどのタスクに十分強力だと気付きました。そこで効率コアを増やすことで、パワーコアを起動する必要性が減り、さらに長いバッテリー寿命（20時間と謳っています）を実現しました。
しかし、純粋にパワーを求めて購入する人は、上位モデルを選ばない限り損をすることになります。ハードウェア設計はすべてトレードオフなのです。一定のダイ面積があり、それをどこかに使用する必要があります。市場のダイナミクスが、より多くの低電力コアを求めているなら、一部のユーザーは不満を感じるかもしれません。より多くのパワーコアを望んでいたかもしれませんが、そういうものなのです。
なるほど。これは理解できてきました。そして、仮想化された言語を使用していることで、人生の中で多くの批判を受けてきましたが、ネイティブ命令にコンパイルされるものを書けばいいのに、と。しかし結局のところ、命令はすべて幻想なんですね。この全体が...アセンブリは事実上、プリアセンブリのようなものです。
チャットで興味深い質問が来ています。私の不完全な回答よりもあなたの意見を聞きたいのですが：なぜ私たちは抽象化された命令セットであるアセンブリを書いて、プロセッサにマッピングを任せるのでしょうか？なぜ直接マイクロ操作を書かないのでしょうか？
素晴らしい質問ですね。二つの観点から考えられます。まず、JavaScriptの視点から答えましょう。これは皆さんに馴染みがあるはずです。特定のハードウェア設計に固有ではない標準を持つことには利点があります。
100%のソフトウェアを100%の時間で再コンパイルし...まあ、Linuxユーザーは同意しないかもしれませんが...
Rustユーザーもですね。
そうですね。でも一般的に、私たちはバイナリの安定性を望みます。そして高レベルな抽象的な理由として、先ほど見たように、PコアとEコアで異なるマイクロ操作が必要になるため、直接コーディングしたくないということがあります。つまり、ラップトップの一つのIntelチップでさえ、二つのコアタイプがあるため、二つの異なるバイナリが必要になってしまいます。
そうです、プログラマーの視点からすると、なぜそれを望まないかという理由がありますが、より深いハードウェアの理由もあります。マイクロ操作は、文字通り、特定のCPUコアが特定のことを最も効率的に実行するための方法にすぎません。例えば加算のような操作です。
ソフトウェアの世界でも似たような考え方をしますが、CPUに何かを送る時、必ずしも文字通り実行したいことを送る必要はありません。写真を見る時に生の画像データを送らないのと同じです。その代わりに圧縮された表現を送り、実際に画像を表示したい場所で解凍します。
ARMやx64のような命令セットは、これらのマイクロ操作の圧縮言語のようなものと考えることができます。レジスタとメモリの位置の間で加算を行いたい場合、できるだけ少ないバイト数でそれを表現する必要があります。実際のCPUコアに到達して処理する準備ができた時に、必要に応じて複数のマイクロ操作に展開できますが、それでもすべてのマイクロ操作を明示的に記述するよりも効率的です。
もう一つの要素として、命令セットを賢く設計すれば、実際に必要な処理のよりコンパクトな表現を得られる可能性があります。メモリ位置での加算という単純なケースを考えてみましょう。CPUの内部で起こる必要のあるステップを考えると、そのメモリアドレスをフェッチし、それをどこかに置き、既存の値を持つレジスタを取り、それらを加算し、別のレジスタに入れる必要があります。
これにはたくさんの冗長な情報が含まれています。メモリの位置から値をフェッチする時、それを加算する予定なので、どこかに置く必要がありますが、マイクロ操作をすべて送る場合、その冗長な情報を含める必要があります。『このものをフェッチしてここに置き、それを取って加算する』といった具合に。しかし、『それを取って』の部分は元のバージョンでは暗黙的でした。CPUがそれを知っているので、私が明示的に指示する必要がありません。CPUは場所を選んで、私はそれを気にする必要がありません。
複数のステップがある場合、冗長なラベル付けが多く発生します。CPUにそれを指示すると、フロントエンドを通過するより多くの帯域幅、より多くのデコードが必要になり、すべてがより多くなってしまいます。そのため、命令セットがどれだけ賢く設計されているかによっては、マイクロ操作を直接エンコードしないことで節約できる場合があります。これがハードウェアの観点からの理由です。
これによって多くのニューロンが発火し、すべてが理合点に来ました。変な例えになりますが、私はアドベントオブコード（毎年行われるプログラミングのリートコードチャレンジ）をよくやります。そこでよく行うのがメモ化で、特定のキーが特定の結果にマップされます。
直近の問題は、奇妙な量子岩の問題でした。毎回瞬きをするたびに、岩は3つの状態のうちの1つに応じて複数の岩になります。桁数が偶数なら2つに分割され、0なら1になり、1なら他の何かになります。ただし、場合によって異なります。
問題の第1部では、25回実行して出力の岩の数を得る必要があります。これは単純な総当たりで可能で、ミリ秒単位で実行できます。非常にシンプルです。第2部では75回実行する必要があり、私が気づいたのは『ああ、これらの順序は重要ではない、このすべてを保存するのは多すぎるデータだ』ということでした。
私たちが気にするのは、1つの数字が何になるかだけです。この数字はこの3つのうちの1つになり、72回実行する必要があれば、単に72を掛けるだけです。この気づきは、これらの命令の1つ1つを、変換先をすべて追跡する辞書のようなオブジェクトにマップできることを意味しました。
そうすることで、私のマシンにはるかに小さな値を渡すことができ、そのマップを使って通常なら命令にエンコードされていたより複雑な部分を理解することで、はるかに小さな応答を返すことができます。アプリケーションに書き込むデータ量や命令の長さを減らすだけでなく、やり取りの量も減らし、命令の複雑さも減らし、CPUが行う必要のある作業量も減らしています。
各チャンクを読んで理解する代わりに、1つの命令を受け取り、それをすべての必要な作業にマップするので、より速いパスで応答を得ることができます。実際に、データの受け渡しの観点からも、その方が速いのです。
はい、そしてこれが、x64対ARM対RISC-Vなどについて話す時に...私がこのようなストリームに出て『ああ、これらは誤解だ』と言い、ALUなどについて説明する理由です。はい、誤解、あるいは誤解と言うべきでしょうか、何が何に影響するかについての誤解がたくさんありますが、命令セットが重要ではないというわけではありません。
命令セットの構造、命令のエンコーディングの方法に関するこれらの選択は、プログラムを実際に表現する際のサイズ、デコードの難しさ、並列デコードの難しさなどに影響を与えます。したがって、命令からCPUが実際に実行することへの変換を扱う部分は、RISC-VとARMとx64を区別する要素の一つです。
最も重要な要素ではありませんが、ある程度は重要で、それはこれらの理由によるものです。
その点について、今Javaが最適なアセンブリ言語だという冗談を我慢するのに苦労しています。しかし、異なる命令セットをマイクロ操作アーキテクチャ、スケジューラー、チップ上に存在するすべての部分の上に構築されたフロントエンドのように考えるようになった今、これらの異なる命令セットの違いは何でしょうか？
そして、それはチップのアーキテクチャ、潜在的なパフォーマンス、そして私の動画で誤って説明しようとしたすべてのことにどのように影響するのでしょうか？
まず、Javaについて一言コメントさせてください。それから質問に移りましょう。
申し訳ありません、挑発的でした。
いいえ、実際に重要な点があると思います。少なくとも私が伝えようとしていることです。プログラミング言語の選択は、プログラマーがこのような命令セットについて教育を受け、選択した言語がこれらのアーキテクチャに対して効率的な命令を生成しているかどうかを監視することに比べれば、それほど重要ではないと私は考えています。
Javaでプログラミングしていても、マイクロアーキテクチャについてしっかりとした理解があり、JavaのJITが何をしているかを監視し、必要な処理に対して妥当なコードを生成していると判断できれば、問題はありません。
一方で、すべてが大丈夫だと思い込んでしまうと、抽象化の層が多すぎたり、悪い実践を行ったりすることで、必要以上に何千もの命令を生成するソフトウェアを作ってしまうような状況に陥ります。
重要なのは、どの言語から始めるかではなく、高レベル言語で書いたものがCPUで実際に何を実行する必要があるのかを理解し、それが適切であることを確認することです。言語の選択が問題になるのは、本当に悪いことをする言語を避けるという点だけです。
それについてもう少し話したいと思います。なぜなら私にもいくつか考えがあり、あなたを面白いプロジェクトに紹介できるかもしれません。これは私の世界だからです。
ここで重要なもう一つの視点は、コードを深く考え、出力を見て、実行しているVMを見る（誰もしませんが、もしするなら素晴らしい）としても、次の抽象化レベル、つまり使用しているライブラリ、取り込むパッケージ、制御できない外部依存関係、そしてそれらの最適化レベルによって制限されるということです。
必然的に非常に複雑なことを行い、最適化が難しいライブラリもあります。JavaScriptの世界で今、とても面白いことが起きています。Hermesプロジェクトについて聞いたことはありますか？
元々は特定のニーズに焦点を当てたJavaScriptの新しいランタイムとして始まりました。FacebookとMetaがReact Nativeアプリの起動時間を改善したかったのです。JavaScriptサイドのReact Nativeアプリのパフォーマンスは良好でしたが、実際の起動時間が遅かったのです。V8がレジスタを整理し、メモリを割り当てるのに時間がかかりすぎていたからです。
Hermesは、JITされた状態をキャッシュして、それをより速く復元できるように最適化されました。そのため、起動時間が大幅に改善されました。他の部分に若干のコストはかかりますが、意味のある程度ではありません。5-10%程度です。しかし起動時間は3倍も良くなったので、大きな勝利でした。
しかし彼らはさらに進もうとしています。実はAmazonが主導しているこのプロジェクトには、Static Hermesと呼ばれる新しいバージョンがあります。これはTypeScriptやFlowなど、型付きのJavaScriptのサブセットまたはスーパーセットを使用する必要があるコンパイラで、その型情報を使用してTypeScriptからアセンブリを生成します。
一見すると、すべてをそれで実行すべきだと思えるかもしれませんが、アプリケーションコードのために完璧に型付けされた厳密なコードを書く人はいないでしょう。しかし私が興奮しているのは、私たちが依存している重いライブラリ、おそらくReact自体のようなものが、アセンブリにコンパイルできる方法で書かれる可能性があることです。
つまり、JavaScriptコードの中で実質的にアセンブリの依存関係を取り込み、言語レベルで、そして理想的にはランタイムレベルでもすべてがネイティブに連携するということです。その魔法に近づいているのです。実際に起きていて、私はその未来にとても興奮しています。
そういったことが増えれば増えるほど、人々がこれらを見て『これは本当に非効率だ、最適化しよう』と考える機会も増えますね。しかし、それが巨大で漠然としたものであり、最初の段階でアセンブリ言語がどのように生成されているのか誰も本当には知らない、あるいはそれに注目していない場合、長い間遅いままになってしまいます。
そうですね。そういったことはたくさんあります。例えば、V8で関数を一定回数実行すると、JITされてより速く実行できるようになります。なぜなら、ネイティブアセンブリに近いものにコンパイルしてキャッシュするからです。
しかし、どの程度強力にキャッシュし、そのキャッシュにどれくらいの頻度で実際にヒットするのかという大きな曖昧な質問には、特にChromeでは良い答えがありません。
Nodeには面白いフラグがあり、キャッシュされたJIT出力を保存するように指示できます。これによってNodeの起動時間が10倍から100倍も良くなります。Verselのような企業は、JIT出力を自動的にキャッシュして、ラムダを起動するたびに生のJavaScriptコードを送信する代わりにバイナリをキャッシュできるように一生懸命取り組んでいます。
JavaScriptの世界でこういったことを見つけ始めたばかりですが、初めてJavaScriptコードから生成されるネイティブなアセンブリ命令を深く考え始めているのです。これは実際にとても興奮することです。
今この動画を見ているウェブ開発者寄りの視聴者の皆さん（チャットを見ているよ、JavaScriptのために来ていることは分かっています）に、これらのことについて話すことで、より多くの人々がこういったことに興味を持ってくれることを願っています。これまで以上に重要になってくるでしょう。
ウェブ開発の中に、インターネットを支える中核的な依存関係を100倍速くできるよう、これらのことについて十分な知識を持つ人々による新しい専門分野が生まれると思います。
確かにその機会はあります。なぜなら、CPUが実際に何をするのかを理解することこそが、そのパフォーマンスを知る方法だからです。CPUがマイクロ操作の観点で何をするのかを基本的に理解すれば、ある程度のことはほぼ正確に実行時間が分かります。
もちろん、データがL1キャッシュから来るのか、L2から来るのかなど、データフローに関する事項はありますが、実際の計算部分について言えば、命令がどのようにマイクロ操作に変換され、何を行うのかを理解すれば、どのくらい速く実行されるかかなり良い見当がつきます。
一方、高レベルのコードを見ているだけでは、その時点ではCPUとは何の関係もないので、本当には分からないのです。そのような心的モデルを持つことはできません。
さて、質問をされましたね。何の違いがあるのかについて。でも、もう一つ役立ちそうな質問があります。どちらから話すか選んでください。もう一つの質問は『サイクルとは何か』です。
そうですね、サイクルについて...つまり、4.8ギガヘルツで動作しているというような時の、CPUサイクルとは何かということですか？
そうです。CPUサイクルとは何か、サイクルはどこで始まりどこで終わるのか...今となってはとても曖昧な用語に感じます。
これは、ハードウェアエンジニアの方が適任だと思いますが、私の理解できる限りで最も大まかな概要をお話しします。サイクルとは何か、あるいはより良い質問としては、なぜサイクルが存在するのか、なぜそれが話題になり、重要視されているのか、なぜ単純に処理時間をナノ秒で語らないのか、という点について説明します。
私の理解では、このような複雑な論理回路を設計する際には、データの受け渡しを調整するために、ステップごとに区切る必要があるのです。言い換えれば、工場の組立ラインのようなものを想像してください。誰かが作業を行い、次の人に渡し、その人がまた作業を行う、というような感じです。
ハードウェア設計者が設計する方法として、電気がチップ内を自由に流れて出力を生成するという方法は、何らかの理由で（私は電気や物理的な仕組みを根本的には理解していないので、これはハードウェアエンジニアの方が適任です）採用されていないか、あまり良いアイデアではないようです。
代わりに、タイミングを制御するためのシリコン部分があり、これが定期的なパルスを送り出して、これがクロックサイクルとなります。現代では、各コアは通常独自のクロックを持っています。コアがブーストできるというアイデアを聞いたことがあると思いますが、以前は1つのクロックレートしかありませんでした。今では低電力状態や高電力状態など、クロックレートの範囲があります。
このような定期的なティックは基本的に、CPUがアセンブリラインの一部で何かの作業を少し行った後、その作業を次の部分に引き継ぐためにあります。実行される作業のパイプラインがあり、例えば14のステージがあるとします。パイプラインステージについて話すと、基本的にCPUはこの順序で処理を行うように設計されています。各ステップの受け渡しはティックで行われます。
実際のCPUパイプラインの図を見ると（残念ながら彼らは決して公開しませんが、どこかで見つけられないか考えてみましょう）...AMDブルドーザーパイプライン図を探してみましょう。以前見たことがありますが、最新のチップではとても見つけにくいですね。
これらのパイプラインステージは、例えば「このパイプラインステージでは命令のデコードを行い、次のステージでそのデコードを完了し、次のステージではマイクロオプキャッシュからの読み込みを行い...」というように続きます。サイクルは、これらのパイプライン内で処理を前に進めるものです。
このブロック図（パイプライン図ではありませんが）を見ると、ここに描かれている各要素の中に様々な種類のパイプラインが存在することが分かります。例えば、ALUユニットの1つに2つのパイプラインステージがあり、少し作業を行い、次にまた少し作業を行う、というように前に進んでいきます。整数リネーマーには1つのパイプラインステージがあり、デコーダーには2つのパイプラインステージがあるかもしれません。
CPUが実際に命令を実行する際は、このようにステップごとにティックティックティックと進んでいき、それらのティックがクロックサイクルで行われます。繰り返しになりますが、これ以上の説明はできません。これはハードウェアエンジニアに聞くべき質問です。秘密でもなんでもありません。ただ私は電気工学者ではないので、その部分についてはお手伝いできません。なぜそうしなければならないのかは分かりませんが、そうしなければならないのです。
この質問に対する最も良い回答の1つは「私は電気工学者ではないので分かりません」ということです。
これは、私や視聴者の多くが理解しようとしていることの1つを明確にするのに役立ちます。どこまで知る必要があり、どこまでは知る必要がないのか。サイクルが実際に何なのかを知らなくても、あなたのような教育的な仕事はできるということですね。私のような人々により深いレベルで仕組みを説明できますが、サイクルが何をするのかについての良い定義を持っていなくても大丈夫なんですね。
Reactと比較するのは良い例です。業界で最高のReactエデュケーターでも、reconcilerが何をするのかについては漠然としか説明できません。私もそのエデュケーターの1人として、まあまあの説明はできます。つまり、クラフトの達人になるために、サイクルとは何かというような基本的なことまで、すべてを知る必要はないということです。より深い理解がなくても、より良いコードを書いたり、よりパフォーマンスの高いアプリケーションを作ったりする妨げにはならないということですね。
その通りです。レベルを1つ上げて、サイクルについて我々が気にする部分は何なのかを考えてみましょう。それは簡単です。先ほど言ったように、CPUはこのパイプラインで命令を実行する必要があり、パイプラインはそのサイクルレートで進んでいきます。つまり、例えば3つのマイクロ操作が必要な命令を見たとき、マイクロ操作は最速でも1サイクルに1つしか実行できません。
実際には1サイクルで実行されているわけではありません。ここには、何かの実行にかかる時間と、それにかかると考える時間のメンタルモデルという、全く別のカテゴリーがあります。スループットとレイテンシーの分析に話が逸れそうですが、興味のある人のために手短に説明します。
ネットワークレイテンシーとネットワーク帯域幅を考えてみましょう。Reactの開発者なら馴染みがあると思います。サーバーから何かを取得して戻ってくるまでには、かなりの時間がかかる可能性があります。40ミリ秒、30ミリ秒、データによってはもっとかかるかもしれません。ネットワークの往復時間があれば、それはもっと長くなり、何をしているかによっては数百ミリ秒になる可能性があります。
1バイトのデータだけを要求した場合、その要求が出て戻ってくるまでに100ミリ秒かかるとします。1秒間に10バイトしか取得できないことになります。誰もそんなインターネット帯域幅では満足しないでしょう。10バイト/秒でファイルをダウンロードするなんて考えられません。
では何が起きているのでしょうか。答えは...あなたはComcastを使っているということですね。（笑）
はい、それもありますが、どうやってそれ以上のスピードを得られるのでしょうか。往復時間がかかることは分かっているのに。答えは、同時に多くのものを送信するからです。サーバーと通信するとき、多くのデータを送ってくれと要求し、サーバーはそれを送り始めます。あなたからの応答を待つことはありません。パイプに大量のデータを押し込み、あなたが受け取ることを前提としています。往復を待つことはありません。
この概念は、CPUパイプラインの動作方法とまさに同じです。命令の実行を開始し、それが非常に単純な命令であっても、開始から終了まで14サイクルかかる可能性がありますが、パイプライン化されているため、毎サイクルより多くの命令をデコードして押し込むことができます。終わりまで待つことはありません。
単一のサイクルを見ると、単一のマイクロ操作は多くの場合、1サイクルあたり約1つの速度で実行できます。これは、CPUのリソースが十分にデコードを行い、毎サイクル1つずつ処理するためです。
実際にチップの総パフォーマンスを見ると、それ以上のことができます。複数の実行ユニットがあるためです。より多くのマイクロ操作でそれらを埋めることができれば、同時に6つ、7つ、8つ、場合によってはそれ以上を実行できます。
つまり、このようなハードウェア分析を行う際にサイクルについて考える必要があるのは、それがCPU側での基本的なクロックであり、何か意味を持っているということだけです。電気工学者でない限り、なぜこの方法を採用しているのかは分かりません。彼らを信頼して、彼らは何をしているか知っているということです。
しかし、この命令ストリームを見て、これらのマイクロ操作を実行する必要があり、それらがこのように依存していて、CPUのサイクル数が1秒あたりこれだけあることが分かれば、この処理にかかる時間をかなり正確に予測できます。そのため、サイクルについてはそのように考える傾向があります。これらのマイクロ操作がどれだけのサイクルで消費されるかということです。
なぜチップにこれらのタイミングクリスタルが必要で、これらのものをバケット化する必要があるのかについては、電気工学者なら簡単に説明できるでしょうが、私には分かりません。
チャットで誰かが非常に良いアナロジーを提供してくれました。オーケストラが指揮者を持ち、全員が同期して動くようにするのと同じだと。さらに私なら、空港の管制官のようなものだと言うでしょう。滑走路にどれだけの飛行機を収容できるか、飛行機がどれだけ早く離陸できるかは関係ありません。重要なのは、飛行機と飛行機の間の時間、1機が離陸した後に次の機が離陸する準備ができているようにすることです。全てが常に動き続けるように調整することです。どの部分の動きの速さではなく、各ステップがどれだけ早く処理されるかということです。
私の頭の中で思い浮かぶもう1つは、少しゲーム開発をした経験から、ティックやフレームについて考えることです。各フレームで次に何が起こるかを処理しようとしますが、これも同じように感じます。各フレームで、その時間に変化したものに基づいて1つから多くのものを前に進めるということですね。
はい、そしてその先は電気工学の問題になりますね。
この答えに満足していただけたようで、チャットの皆さんも比較的満足しているようですね。では、ARMとRISKとCISKの違いについて話しましょうか？
はい、これは常に少し難しい話題ですが、できる限り説明してみましょう。まず、高レベルでの誤解を少し解消できると思われる、かなり分かりやすいことから始めましょう。
あなたの動画で、RISC-5の命令数は40程度で、除算さえ持っていないと言及していましたね。RISKファイブには除算がないと。ARMにもないのかもしれませんが...申し訳ありません、続けてください。
はい、それは私が知っているのは、私が大好きな他のテクノロジーYouTuber、Low Level Learningが、私たちの友人グループの一員になったからです。彼がARMのCPUを指して「計算ができない」と書いたサムネイルとブランディングがとても良かったので、彼に連絡を取り、今では良い友人になっています。今もライブを見ているかもしれません。まだチャットでは見ていませんが、普段は立ち寄ってくれます。私は彼の動画のブランディングについて、事実としてよりも詳しく知っていますが、動画の主なポイントは、ARMチップのような物が除算命令さえ持っていないということでした。
では、その誤解を正してみましょう。それがどこから来たのかは完全には確信が持てませんが、推測はできます。後で説明しますが、まず何か説得力のあるものをお見せしましょう。
Compiler Explorerを開きました。このツールをご存知ない方もいるかもしれません。これはウェブツールで、本当に素晴らしいものです。基本的に、コードを入力することができ、アセンブリ言語にコンパイルできる言語を多数選択できます。左側にコードを入力できます。
ここで、渡された数値で1を割る関数に変更してみましょう。これはCですが、基本的にどの言語でも同じような感じになるはずです。整数を取得して1をその整数で割る関数です。
実際のところ、私はHCaLしか書いたことがありません。これらが何なのかわかりません。
機能的なプログラミングですが、それさえも機能的なプログラムですね。関数です。
副作用のない、値の定義もない機能的なプログラミングということですね。
右側では、コンパイラを選択すると、出力が表示されます。上部にスイッチを付けることもできます。Matt Godboltによって作られた本当に素晴らしいツールで、教育目的には最高のツールの1つです。このような種類の教育用に作られた中で、私が見た中で最高のツールの1つです。
反対側にアセンブリ言語の出力があり、これらが全て何をするのかについては説明する必要はありません。これはアセンブリ言語を学ぶためのストリームではありませんから。ここに除算を行うIDiv命令があります。まさにここにあります。
これが我々の関数で、これがそのコードです。これは最適化されていないコードです。最適化するように指示することもできますし、そうすればもっと小さくなるでしょう。もっと創造的なことができる可能性がありますが、今は何が起きているのかを単純化しないようにデバッグコードのままにしておきます。
ここにIdiv命令があります。そして提案されているのは、x64がこの除算を行う命令を持っているのに対し、ARMとRISC-5はそれを持っていないということですね。つまり、ループのような一連の命令で除算を行わなければならないということが示唆されています。よく分かりませんが、あなたが除算がないとはどういう意味だと思っていたのか教えてください。
乗算でハックしているのかと思っていました。
そうですね。何か異なる乗算の処理をしているか、誰にも分かりません。しかし、ここでできることは、ARMのコンパイラを選んでみることです。32ビットのARM Clangを選びましょう。いや、64ビットバージョンを選びましょう。64ビットで統一しておきましょう。
ここに64ビットのARM Clangがあります。これは例えばMシリーズのMacなどのARM 64用にコンパイルするものです。ご覧ください、除算命令があります。SDIVと呼ばれ、IDIV命令とほとんど同じようなことをします。これがARMアセンブリです。
では、RISC-5も見てみましょう。ここにRISC-5のコンパイラオプションがあります。同じくClangを選びましょう。少し時間がかかっています...はい、ここにDIVW命令があります。これがRISC-5の除算命令です。
皆さんが自分の目で見ることで、今日購入できるような現代のデスクトップCPUやラップトップCPUで、ネイティブの除算命令を持っていないものはないということを信じていただけると思います。ARMでもRISC-5でもx64でも、全て持っているのです。
ここでDIVがHTMLのdivのように区分けを意味するのではなく、本当に除算を意味することを確認できますか？アセンブリの中にHTMLを入れているだけではないですか？
はい、それは良い指摘です。しかしここにRISC-5のDIV命令のドキュメントがあり、下位32ビットを他のレジスタの下位32ビットで割ると書かれています。
さて、私は今、私の良い友人の1人が、インターネット上で広めた誤情報のおかげで知り合った人だということを反省しなければなりません。エド、私たちには解決すべき問題がありますね。
いや、実際には彼にこれを送るのがとても楽しみです。彼はきっとフォローアップ動画を作ると思います。それはほぼ確実です。
私があなたとの間に軋轢を生んでしまったことを申し訳なく思いますが、それが素晴らしいYouTubeコンテンツになるなら、申し訳なくも思いませんね。リアクション動画として最高ですから。
しかし真面目な話、アーキテクチャや命令といった伝統的に退屈だと思われていたものを、私たちが複数の動画を作れるほど面白くできたことは、それ自体が大きな achievement です。そして、このような分野のオタクとして、私はそれを大いに感謝しています。こういった話をする機会はなかなかありませんから。
私もそうしようとしています。人々に興味を持ってもらいたいので、面白くしようと努力しています。
それで、なぜこのような誤解が広まったのでしょうか？私にはその理由が分かる気がします。ARMやRISC-5のようなライセンス可能なアーキテクチャについて理解しなければならないのは、彼らが販売しようとしているということです。RISC-5は伝統的な意味での販売ではありません。オープンなISAなので。しかし、それでも採用されることを望んでいます。誰も命令セットアーキテクチャを作って、それを使ってもらいたくないなんて思わないでしょう。
私はReactを売り込むために雇われたシルだと非難されることがよくありますが、Reactが人気になることで誰かがお金を稼ぐわけではありません。むしろチームの維持にはより多くのコストがかかります。使われることを望むのは、必ずしもお金を稼ぐためではないのです。
それと対照的に、x64はIntelとAMDのものです。彼らはそれを定義して、チップを出荷します。他の人に販売しようとはしていません。実際、他の人が使うのを防いでいます。ARMとRISC-5は、使用を促進しようとしているため、できるだけ広く使われることを望んでいます。ISAの単一の定義だけを出荷することはしません。
公平を期すために、Intelも本当の意味では単一の定義だけを出しているわけではありません。このチップはAVX 512を持っているのか、持っていないのか、というように言いますよね。そのため、ISAの一部を分割するという考え方はあります。しかし、それは今は置いておきましょう。
ARMやRISC-5の基本ISAでさえ、そのような方法では機能しません。代わりに、何かができる最小限のセットを定義し、他の全ては「拡張」と呼ばれます。例えば、RISC-5ではM拡張と呼ばれ、乗算と除算のためのものです。ここで実際にマニュアルを見てみましょう。
PDFでドキュメントを見なければならないのは、大学で何かを使っていて以来ですね。今はすべてAlgoliaの検索が組み込まれたファンシーなウェブページがありますから。
私もそのようなものが欲しいですね。これらを見つけるのにはかなり時間がかかります。面倒くさいですね。M拡張と呼ばれているはずですが...ここにありました。
RISC ISAの第13章です。「整数の乗算と除算のためのM拡張」とあります。私はここからこのアイデアが来ていると思います。つまり、技術的にはRISC-5チップを除算器なしで作ることができます。乗算器なしでも作れます。実際、M拡張をサポートしない場合、これらのどちらも実装する必要はありません。
おそらく、このような算術を全く行わないような、非常に簡略化された特定の目的のためのRISC-5チップもあるでしょう。例えば、何らかの方法でパケットを処理するだけで、乗算や除算は行わず、ただビットを移動させるだけのルーターのようなものです。その場合、「私たちはこれでRISC-5に準拠していますが、M拡張はありません」と言うのを簡単にしたいのです。そうすれば、これらを実装する必要はなく、それでも技術的にはRISC-5準拠のチップとなります。
RISCチップがこのような乗算器や除算器を持っていないという考えは、技術的にはオプションだということから来ているのだと思います。拡張をサポートしないことを選択できるのです。しかし、技術的にオプションであることと、「AppleのMシリーズは除算ができない」というのは全く異なります。除算はできます。強力な除算器を持っているのです。
そのことを明確にしておきたいのですが、人々がもう少し状況を理解できるように。この点について何か質問はありますか？先に進む前に。
では、コンパイラは今、コンパイル時に利用可能な命令セットのどのサブセットにアクセスできるかをより考慮する必要があるのでしょうか？例えば、特定の種類の除算を期待するCコードを書いた場合、コンパイラはそれを処理するために拡張が必要になるのでしょうか？
はい、コンパイラは知る必要がありますし、私がこの方法で実演したのは、おそらく視聴者にとってより説得力があると感じたからです。RISC-5のデフォルトのコンパイルは除算があることを前提としています。なぜなら、当然そうですよね。でも、あなたの指摘は正しいです。
M拡張を使用しないRISC-5コードを出力したい場合は、除算がないことを示すアーキテクチャフラグが必要になります。そうすれば、エミュレートされた除算を出力するなどの処理が必要になります。
確かにそれはできますが、これはとても一般的なので、デスクトップコンピュータやラップトップコンピュータで除算命令を持たないARMチップで実行することは誰も期待していません。そのため、デフォルトでそれを出力します。
コンパイル時にアーキテクチャフラグを設定する必要のあるものはたくさんあります。先ほど例に出したAVX 512は、多くのチップがその命令セットを持っていないので、おそらくAVX 512対応の命令セットだけにコンパイルすることはないでしょう。実際、AVX 512命令セットには、個別に有効化できる複数の部分があります。
そういったことは全て事実です。コンパイル時には、命令セットについてそのようなことを知る必要があります。除算は通常前提とされる機能の1つです。もし除算器を持たない組み込みデバイスで使用する場合は、そのことを指定する必要があります。「このちっぽけなマイクロコントローラーには除算器がないんです」というようにね。
これは非常に参考になります。チャットで見かけた点で、明確にしておくと良いかもしれないのは、あなたが選んだRISC-5のclangオプションのRV 64 GCの「G」は「General（一般）」を意味し、除算は一般的なRISCコンパイラに含まれているということです。これは非常に理にかなっていますね。
そうですね。私がストリームを見ている人なら知っていると思いますが、私はフラグを全て覚えていることはありません。今、もしMartin Mosaicoのように知識があれば、除算を無くすためにアーキテクチャを切り替えるための何かを入力できることを知っているはずです。私はそういったことを毎回調べなければなりません。
申し訳ありませんが、それをデモンストレーションできませんが、そのようなものをオフにする方法は確実にあります。ただ私は覚えていないだけです。
20年前の縮小された命令セットを持つ5セントRISCチップに多くのゲームをコンパイルしたことがないということですね。
はい、そうです。それで、これは比較的説得力のある議論だと思います。では次に、これらの命令セットの実際の違いについて話しましょう。
まず、大まかな概要として言えることは、一般的にこれらのものの軌跡は、おそらくISAよりもはるかに重要だということです。ARMは低電力として始まり、それ以来ずっと低電力を維持してきました。その存在の歴史全体を通じて、常に低電力に焦点を当ててきました。
一方、x64（最初はx86として始まった）は決してそうではありませんでした。決して低電力を意図したものではありませんでした。
興味深いことに、ARMはオープンで、誰でもライセンスを取得でき、多くの人々が同じ命令セットアーキテクチャを実装する異なるマイクロアーキテクチャ設計で競争できました。私は、これが今日見られる結果に、これから話すことよりもはるかに大きな影響を与えていると言って間違いないと思います。
これらの違いに実際の理由がないというわけではありませんが、ARMサイドでは多くの競争、特に低電力に特化した競争があり、多くの企業がそのISAで低電力チップを作ろうとしていたことを覚えておく必要があります。x64/x86ではそれは決してなかったのです。低電力が話題になったのは、唯一の2つのプレイヤー（実際にはViaなど、x86には時々他の企業もありましたが、ほとんどはAMDとIntelだけでした）が競争していた時だけでした。ほとんどの場合、彼らはハイエンドとデータセンターで競争していました。低電力への焦点を当て始めたのは最近のことで、その面でも良くなってきています。
ビジネス上の懸念、競争、どれだけオープンだったか、どれだけの人々が何かを試みようとしていたか、これらのことが、これから話すことよりも、今日のARMとx64の状況に大きく関係していると思います。そのことを覚えておいてほしいと思います。
そうですね、ビジネス上の懸念は違いを生みます。Intelの最新のリリースを見なければ、私もこれについて疑問を持っていたでしょう。ようやく、バッテリー寿命が一桁時間単位で測られないx864チップを出すようになったんです。彼らはついにそれを実現する方法を見つけました。時間がかかりすぎましたが、それほど時間がかかったことで、Appleは自分たちでそれを実現する方法を見つける必要に迫られました。
Appleは、小さな12インチMacBookに入れられるような、パワフルでありながら十分に低電力なx86チップを作るためにIntelと協力しようとしました。その時点での彼らのIntelとの frustration が、Apple Silicon への完全な移行につながったのです。これはビジネス上のインセンティブでした。彼らはチップに特定の目標があり、チップ製造パートナーがそれを実現できなかったので、独自の道を進むことにしました。ARMは彼らが独自の道を進むための最善の方法だったのです。そして繰り返しになりますが、ARMは低電力に焦点を当てて多くの作業が既に行われていたので、彼らはゼロから始める必要はなかったのです。
そうですね、低電力への焦点はそこにあったということです。先ほど言ったように、最初のARMチップでさえ低電力でした。これは以前のストリームで出てきた話だと思いますが、真実だと言われている逸話があります。
最初のARMチップ（つまりAcornコンピュータ、BBCマイクロの人々が作ったもの）を開発していた時、最初の...というか初期の頃、チップが動作していることに気付き、電源が入っていないことに気付いたそうです。チップに電力が供給されていないのに動作していて、ボード上の他のものからの残留電力がARMチップに漏れているだけで、低電力すぎて機能していたことが分かったそうです。
これは完全に信じられない話に聞こえますが、複数の人から、これは本当だと聞いています。細部は間違っているかもしれませんが、このことは元のチームによって繰り返し語られているそうです。それほど低電力で始まり、常に低電力に焦点を当ててきたのです。
しかし、今日我々が気にする実際の違いは何でしょうか？複雑さは確かに1つの要因だと思います。まずRISKとCISKの話から始めましょう。これは確かに存在する違いですが、それほど重要な点ではありません。そのことをまず明確にしておきたいと思います。
元の論文を見てみましょう。RISKについて初めて語った論文のPDFがあります。世界に向けて「これが我々がやってきたことです」と発表する論文です。当時、多くの人々がこのアイデアに取り組んでいて、これは彼らがやってきたことについて書いた論文でした。RISKについて説明し、その理由を主張しています。
彼らはRISKの特徴をまとめようとして、次のように述べています：「操作はレジスタ間で行われ、メモリにアクセスするのはロードとストアだけである」。先ほど例に出した加算命令を覚えていますか？その加算命令がメモリを操作として使用できるのは、x64での話です。ARMではそうではありません。元々のRISKの考え方では、個々の命令がメモリにアクセスすることはありません。メモリにアクセスするための特定の命令があり、まずその命令を実行し、次に別の命令を実行します。
「操作とアドレッシングモードは削減されている」というのは、まあ、実際にはどの程度削減されているのかは明確ではありません。「命令フォーマットは単純で、ワード境界を超えない」というのは、単に固定サイズということです。命令のサイズが固定されているということです。
あなたの動画からその部分を具体的に覚えています。ARMとRISCでは命令は常に同じ長さでなければならず、Intelではそうではないということですね。
はい、x86ではそうです。そして「RISKブランチはパイプラインのペナルティを避ける」というのがありますが、これは当時は真実だったものの、遅延分岐について話すことはありません。これはもはや真実ではありません。
これはPatterson（おそらく皆さんご存知のコンピュータアーキテクチャの本の著者）による要約です。単なる誰かが書いたものではありません。
そして当時、これに対する反応として書かれたものを見つけました。これは良いと思います。基本的に、今日私が指摘するような点を指摘しています。「命令セットがどれだけ複雑か、あるいは削減されているかについて、何を言っているのか分からない」と不満を述べています。
これは連続体ですよね。複雑な命令を持つことも、持たないこともできます。複雑なことを行う命令をたくさん持つこともできます。それらをどれだけ持つべきかは別の問題です。RISKと言うとき、実際に何を意味しているのでしょうか？これはRISKなのか、CISKなのか？それらの4つの漠然とした点だけでは分かりません。
彼らは、チップをそのような視点で見ることが興味深いアプローチではない理由について語り続けます。当時でさえそうでした。そして、当時彼らが話していたことのほとんどは、基本的に今日でも同じです。RISKとCISKはそれほど明確に定義されていません。
特定のチップやISAがRISKかCISKかを誰かに尋ねた場合、その判断の仕方は本当に分かりません。時には非常に明確な点があります。例えば、「ロードとストアは他の命令の一部にはできない」という点だけが基準であれば、x64はCISKで、ARMはRISKだと言えます。なぜなら、一般的にそれらのルールに従っているからです。完全にではありませんが、ほとんどの場合はそうです。
しかし、彼らが話していた他のことについては、必ずしもそうとは限りません。遅延分岐の話は今日では全く当てはまりません。このことが私たちの頭に stuck してしまい、RISKとCISKがあたかも重要な事柄であるかのように話すようになってしまったのです。
しかし、現在に至ってみると、誰もが私が示したようなマイクロアーキテクチャを使用しています。命令はマイクロ操作に変換され、マイクロ操作が実際に実行されます。Intelは他の誰よりも多くの命令を持っているでしょうか？おそらくx64ではそうです。
非常に古いアーキテクチャで、多くの後方互換性を維持してきたため、多くの古い命令を持っています。そのうちの多くは今では全く使われていないかもしれませんが、まだ存在しています。しかし、RISK-5やARMを見ると、それらは今ではもっと複雑になっています。現代のRISK-5チップは、命令セット設計の面でもx64チップとよく似ています。
それを示しましょう。例えば、数値計算を行う際に重要な役割を果たすベクトル命令セットを見てみましょう。RISK-5チップが数値計算で競争力を持つために必要なV拡張というものがあります。つまり、科学的な計算など、そういったことを行うために必要なものです。
ここに「ベクトル要素のベクトルレジスタ状態へのマッピング」というセクションがあり、ELMOと呼ばれるものについて説明しています。これはプロセッサで設定できる状態で、より大きなまたは小さなレジスタに様々なレジスタを組み合わせる方法を指定する命令です。そうすると、操作を行う際に指定したレジスタ以外のレジスタにも自動的に適用されます。
これがRISKだと言えるでしょうか？我々が直感的に理解しているRISK、つまり「非常にシンプルで、複雑なものではない」という理解からすると、そうとは言えません。これは「削減」の定義とは正反対です。これは意図的に命令を拡張し、複雑にしているのです。
ELMOが設定されている可能性があり、以前は1つのレジスタでしか操作しなかったものが、今では2つのレジスタで操作する可能性があるということを、他のすべての命令が理解しなければならないのです。
私の説明は、実際よりも複雑に聞こえるかもしれません。プロセッサ内部のこれらのものは、このレベルで考えるようなものではありません。プロセッサ内部では、実際にはレジスタというものは存在しません。レジスタ名があり、その名前を使用する際にレジスタファイルと呼ばれるものが使用されます。
しかし、私が言いたいのは、これは単純ではないということです。ベクトル計算を行うための最も単純で基本的なバージョンを作ろうとした場合、このようなものにはならないでしょう。
私の要点は何でしょうか？これらの命令セットは、現時点で実際には同じことを行っています。プログラマーが行おうとしていることを、チップが迅速にデコードし、迅速にマイクロ操作に変換して、迅速に実行できるような方法でコンパクトにエンコードする命令セットを見つけようとしているのです。
もはや誰も、このようなものを設計する際にCISKかRISKかについて考えていないと思います。それは単に問題ではありません。複雑さがどの程度かは、実際には問題ではありません。むしろ、プログラマーが行いたいことを、このパイプラインを通じて迅速に実行されるような方法で、どのように効率的にエンコードできるかということです。
CISKとRISKの議論を始め、そのような名前付けを行った当時、彼らはマイクロコードが無料のようになるとは考えていませんでした。マイクロ操作への変換が単なる過程の一部になるとは考えていませんでした。RISKデザインではそのようなことを全くする必要がない、あるいはほとんどする必要がないと考えていたのです。
しかし、今日では誰もがそれを大量に行っています。これらの大きなチップ、デスクトップやラップトップのチップでは、マイクロコードが全く必要ないような、本当に単純化されたバージョンを作っている人はいません。
これをパズルの2番目の部分として説明したかったのです。RISKとCISKは一種のレッドヘリング（誤った方向に導くもの）のようなものであり、ハードウェア設計者が今行っていることを本当には捉えていないと思います。彼らはもはやそのことについて考えていないと思います。
分かりますか？
それは完全に理解できます。これは80年代の議論で、2つの異なる道が探求されましたが、これらの道を辿った結果、私たちは似たような場所に到達しました。1つの道を赤、もう1つの道を青と呼んでも、今や紫に到達しているのですから、もはや重要ではありませんね。
それは完璧な要約です。絶対に完璧な要約です。
そして、その背景を踏まえた上で、これらのISAの具体的な違いで重要なものはあるのでしょうか？ロードとストアが分離されているということは、重要ではないと思います。ロードとストアを一緒にできるISAを簡単に設計できると思います。そのRISKリストの部分はそれほど関係ないと思います。
それらのRISKリストの多くの項目は、それほど重要ではなかったと思います。しかし、1つ重要なことがあります。それは命令のエンコーディングの規則性です。これは、私がPrimeとのストリームで話していたことだと思います。
これらのブロック図に戻って見てみましょう。Firestormコアをもう一度見てみましょう。これは、Mシリーズチップのヘビー級コアですが、ここで注目すべきは多くのデコーダーがあることです。
ここに8つのデコーダーがありますが、これは命令を受け取ってマイクロ操作に変換します。クロックサイクルごとに、このパイプラインを通じて8つの新しいマイクロ操作が供給されることを意味します。命令ストリームを実行できる最速の速度は、明らかにそれをデコードできる速度によって制限されます。デコードが十分に速くできなければ、実行できる計算リソースがたくさんあっても、何をすべきか分からず、待機しているだけになってしまいます。
このチップの上部、この部分が実行部分を十分に速く供給できることを確認する必要があります。これはARMのような製品では非常に簡単です。命令が固定サイズなので、これらの単純なデコーダーを配置できます。各デコーダーは、他のデコーダーから固定幅だけ離れた場所から始まることが分かっているため、並列で全てをデコードできます。サイクルごとに8つずつ、88888と処理できます。その結果、この部分は決して作業不足になることはありません。
一方、Zen4の同じ図を見てみると、「複雑なデコーダー」「複雑なデコーダー」「複雑なデコーダー」となっています。分かりますか？
はい、既にその表現の違いがありますね。「複雑な」デコーダーと呼ばれています。
はい、これは彼らにとってはるかに困難です。何かをデコードする必要があるとき、次の命令がどこにあるか分からないため、より多くの作業が必要です。これはIntelのエンコーディングが可変長命令だからです。
基本的には同じような方法で動作します。圧縮について馴染みがあるかどうか分かりませんが、バイトを読み込んで、次のバイトがこれかあれかを判断するような感じです。このバイトがこれなら、次のバイトはこれだと分かる、というような仕組みです。
これを行うこと自体は大きな問題ではありません。問題は次のデコードをどこから始めるかを知ることです。Macのように8つ同時に処理したい場合、最初のデコーダーは現在のプログラムポイント、つまりデコードポインタの位置から始めることは分かっています。しかし、次のデコーダーはその後のどこかから始める必要がありますが、その位置が分からないのです。
そのため、ビットフィーディングに基づく複雑な推測のようなことを行って、正しく推測することを期待します。通常、ほとんどの命令は最良の場合、迅速にデコードできますが、他のケースに遭遇すると遅くデコードされます。そして、ここには4つしかデコーダーがないことにも注目してください。
ここで乗算が見られますが、これらの図は community made なので、慎重に扱う必要があります。間違っている可能性もあります。Zen4のエンジニアは今、私たちを笑っているかもしれません。真実を知っているからです。これは例として正しいことを願っていますが、保証はできません。
前の図と比較してみましょう...ここから出ていくマイクロ操作を見ると、各デコーダーから基本的に1つのマイクロ操作が出ていきます。サイクルごとにということだと思います。
つまり、このパイプラインを通じてマイクロ操作を流すことができるかどうかに偏りはないということです。どのような命令を実行していても、1つのマイクロ操作しか生成できない非常に単純な命令であっても、8つのデコーダーがそれぞれ異なる命令をデコードしているため、8つの命令を実行できます。
一方、こちらを見ると、これらの各デコーダーはサイクルごとに2つのマイクロ操作を出力できます。合計8つのマイクロ操作で、かなり良さそうに聞こえます。問題は、それらを集めるための命令が4つしかないことです。その4つの命令がそれぞれ2つのマイクロ操作をコードとして持っていない場合、実際には8つのマイクロ操作をパイプラインに送ることができません。
結果として、デコーダーロジックにそれだけの余裕がないか、それを解決するのが難しすぎるなどの理由で、パイプラインを流れるマイクロ操作の数を保証できない状況になります。分かりますか？
はい。私の頭の中で、これまで以上に他のことと関連付いているか確認させてください。全く的外れな場合は、それは後の問題として、そう言っていただいて構いません。
これは、x86チップに存在する予測モデリング（何という用語か分かりませんが）の理由なのでしょうか？命令に基づいて次の命令を予測し、エンコードされていないかもしれない命令を準備しておくというものです。
いいえ、それは投機的実行と呼ばれるもので、これらのコア全てで行われています。
それについて話したいですか？今話すこともできますし、後回しにすることもできます。
後回しにしましょう。私は単に、このアーキテクチャでは十分な命令とマイクロタスクを通すことが難しいので、より多くを持つことが有益だから、それが興味深く重要なのかと思っただけです。でもそうではないようですね。
それは別のことです。投機的実行については話せます。ARMコアも全く同じ問題を抱えています。その話は確実にできます。
この部分を締めくくらせてください。ほぼ終わっていますから。繰り返しになりますが、私はハードウェア設計者ではなく、情報も持っていないので、ここで起きていることの詳細は説明できません。
しかし、よく見られるのは、x64チップのこの部分に多くの努力が費やされ、より多くの命令を同時にデコードする方法を見つけようとしていることです。これは、AppleのMシリーズなどでは全くそうではありません。それを作った時、一度に何をデコードするかについて誰かが頭を悩ませていたとは思えません。むしろ「それはそのくらいの大きさになるのか、了解」という感じだったでしょう。おそらくここでは誰の博士論文プロジェクトにもなっていなかったでしょう。
本当にばかげた例えを挙げると、CPUアーキテクチャを台所に例えるのが好きです。コアはシェフの数のようなもので、現実世界で理解しやすいものです。ここではほとんど、切る必要のある食材が入ってくるようなものと考えることができます。パンだとしましょう。
単純なデコーダーの場合、パンの各スライスは常に正確に同じ長さです。事実上、予めスライスしておくこともできます。それぞれのスライスがそれぞれのデコーダーに流れていきます。
Intelバージョン、x86の場合、パンは理論的に2スライス幅、またはそれ以下になる可能性があり、それぞれがどれくらいの長さなのか確認し、正しい場所で切る必要があります。基本的に、フランスのバゲットを渡されたり、アメリカのサンドイッチ用パン、ワンダーブレッドのような食パンを渡されたりするようなもので、何が来るか全く分からないのです。完全な悪夢です。
一方、もう一方は完全に規則的で、常に正確に同じ大きさのパンで、8つの刃を等間隔に配置した小さな機械を作るだけで、シュッと切れるのです。
そしてこの部分は、ある程度本当に重要だと思います。これは実際に指摘できる問題を生み出しています。x64のエンジニアは、それが問題でなければ、もっと早くより多くのことができたはずです。
繰り返しになりますが、彼らがここにいてそれが本当かどうか教えてくれればいいのですが、それは指摘したい点の1つです。ARMには少し有利な点があるということは嘘ではありません。しかし、私の動画と比較すると、私は「これは図全体を通じて重要だ」と言いましたが、実際にはこれが重要なのは、もし図を少し拡大してみると、オレンジ色のセクションだけなのです。
その通りです。多くの人が、私も含めて、この図のもっと多くの部分がこの会話に関連していると誤解していましたね。
その通りです。これがARMが重要な部分です。あるいは長期的に有利になる可能性がある部分です。限界に達すると、可変長命令エンコーディングは本当に望ましくないかもしれません。
あるいは、もう1つの可能性として、可変長命令エンコーディングは望ましいけれど、もっとスマートな方法で行いたい、つまりバッチデコード向けに設計された方法で行いたいということかもしれません。x86、そしてその後のx64命令セットが設計された時、彼らは「毎サイクル8つの命令を同時にデコードしたい」とは考えていなかったことを覚えておいてください。
他にも違いはありますか？実際にあります。Intelが持っていてARMが持っていないものの1つで、ARMが有利になる可能性があるのは、Intelはより厳密なメモリオーダリングを持っているということです。
CPUコアが何かを書き込むとき、それがいつ見えるようになるのか、あるいは何かを読み込むときに他のCPUコアがそれらを変更している可能性があるときのルールは、Intelの方がARMよりも厳密です。ARMはより緩やかなメモリオーダリング、あるいはメモリオーダリングモデル、単にメモリモデルと呼ばれるものを持っています。
技術的には、そのメモリモデルを保証するのは少し困難、あるいは「困難」というのは間違った言葉かもしれませんが、パフォーマンスの面でコストがかかる可能性があります。これが将来的な要因になるかどうかは不明確です。私は確実なことは言えませんし、誰もこれについて決定的な分析を行っているのを見たことがありません。
しかし、人々がMシリーズでテストを行い、そのモデルを使用しないことで9%程度のパフォーマンス向上があるかもしれないということを発見したと言いたいと思います。これは、動画で言及した点に関連していて、実際に前に触れた話に戻りますが、M シリーズがRosettaのために何かをチップに組み込んだと言っていましたよね。
はい、それがM シリーズチップの1つの特徴です。通常のARMチップはARMメモリモデルしか持っていませんが、これはリラックスドメモリモデルです。M シリーズチップは両方のメモリモデルを持っていて、ARMメモリモデルかIntelメモリモデルのどちらかを使用できます。
なぜそうしたのでしょうか？これはx86をARMでエミュレートする際の非常にコストのかかる部分の1つだからです。これは動画で触れた部分で、除算の話をしていた時点では少し脱線気味でした。除算がないから除算をエミュレートしなければならない、というのが問題ではありません。問題は、マルチプロセッサ環境で物事がどのような順序で見えるかという、本当にエミュレートが難しい部分なのです。より厳格なメモリモデルをエミュレートするために、余分なミキシングやフェンスなどを入れなければならず、それが非常に重くなってしまいます。
一方、CPUが自体がそれを保証してくれれば問題ありません。実際、M シリーズでRosettaをサポートするために追加された機能を見てみると、除算などとは関係ありません。というのも、既に除算機能など持っていて、非常にパワフルなチップだからです。必要だったのは、メモリモデルをエミュレートすることでした。CPUがそれをネイティブにできれば、より良いパフォーマンスが得られます。
Snapdragonはそれができず、エミュレーションのコストがかかる部分だと思います。ただし、新しいSnapdragon x86マシンについては詳しくないので、これは引用しないでください。
もう1つは、フラグレジスタという概念です。これについては長くなりそうなので、どのくらい配信を続けたいか分かりませんが。17時間後...（笑）。操作を行う際に追跡される要素があります。例えば、2つの数字を足し合わせた結果が収まらない場合、つまり32ビットの数字を2つ足して結果が収まらない場合、33ビット目がセットされてキャリーフラグと呼ばれる状態に入ります。これはプロセッサが追跡する状態です。
そしてそれに依存する操作を行うことができます。例えば、キャリーフラグがセットされているかどうかに基づいて分岐することができます。これは仮説的な例ですが。
これらは、プロセッサを設計する際に考慮できる要素です。IntelのフラグセットとARMのフラグセットでは、フラグがいつ追跡され、何を意味するかが異なります。実際、動画でこの話が出てきたので、リソースを調べてみました。私自身あまり研究していない分野なのですが、ダグラス・ジョンソンという方が素晴らしいリバースエンジニアリングを投稿していて、実際に何が追加されたのかを調べていました。
その結果、Intelのようにフラグを機能させるための機能が追加されていたことが分かりました。これにより、エミュレーション中にフラグ操作を追跡するために多くの重い操作を行う必要がなくなりました。CPUがIntelと同じようにフラグを記憶するだけでよくなったのです。
はい、メモリモデルの話もありましたね。そして「Appleの秘密の拡張」というのが最後にありましたが、これもフラグの処理に関するものだと思います。そうですね、これも同様に、フラグを計算するための算術演算を自分で行う必要がなくなり、依存する操作を適切に行えるようになったということです。
私の推測では、間違っているかもしれませんが、Appleは古いx64のものを誰も気にしなくなった時点で、これらを取り除くのではないかと思います。マイクロアーチテクチャからこれらを取り除くでしょう。現時点では、iPadのCPUなどM シリーズCPUを使用しているデバイスでもこのアーキテクチャが残っていると理解しています。
彼らの製造プロセスはまだそれほど考慮されていませんが、将来的にはそうなると思います。あるいは、チップが非常に高速になってきているので、これらの機能をより高レベルのソフトウェアエミュレーションに移行する可能性もあります。古いIntelプログラムを実行する場合、特定の速度で動作することに慣れているでしょうから。
私はRosettaなしで1年ほど過ごせたと思います。Rosettaはプログラムをインストールする必要がありますし、実際長い間それなしで過ごしていました。
申し訳ありませんが、戻っていただけますか？他にも指摘したい点がありました。「Appleの秘密」の部分の直後に、もう1つ触れたい部分があったのですが...どこだったかな...はい、そこに見えています。
その前に...申し訳ありません、話が脱線してしまいました。大丈夫です。ここには、以前議論した命令のパース方法やスループットに関連する非常に興味深い部分があります。「スループットバウンドを避けるため」という記述があり、これは以前話した内容と関連していると思いました。
歴史的に、プロセッサ上で実際の計算を行うチップに到達できる実際のスループットを心配する必要がありました。Appleのアーキテクチャは、それが起こり得ない最初のパワフルなCPUアーキテクチャの1つです。
彼らが行ったことの1つは - そして彼らがそれを行ったのは良いことだと思います。なぜなら、それによって誰もが向上せざるを得なくなり、全体的な水準が上がるからです - 基本的に「全力を尽くそう」と言ったのです。大きなチップを作り、多くの機能を搭載し、8つのデコーダーを持ち、多くのALUと実行ユニットを持つことにしました。
そして、すべてのパイプラインを本当に深くし、非常に大きなレジスタファイルを持つことにしました。すべてを大きくして、毎サイクルでできるだけ多くの作業を行えるようにしました。チップのどの部分も制限要因にならないようにしたのです。
そしてそれは機能しました。シングルスレッドのコードに関して、これが重要な部分ですが、それらのFirestormコアは素晴らしい仕事をしています。すべてが非常に大きいからです。私のiPadは、最高のデスクトップチップでさえもシングルスレッドで上回っています。これは信じられないことですが、Appleがそこまで押し進めたのです。
チャットで誰かが思い出させてくれましたが、以前話していたのはRosettaのダウンロードについてでした。Rosettaにはマシン上にソフトウェアコンポーネントが必要で、デフォルトでは付属していません。後方互換性を必要とするプログラムを使用する時にインストールする必要があります。
私は数年間、それなしで過ごしてきました。特殊なオーディオソフトウェアを使う時だけ必要でした。私はiZotopeのオーディオソフトが大好きで、3〜4年の間でRosettaをインストールしたのはそれが必要な時だけです。
ほとんどの人がこれを必要としておらず、それから離れつつあるというあなたの指摘は全くその通りです。Rosettaに多くの努力が注がれた理由の1つは、AppleがAppleシリコンへの移行がどれくらい早く進むのか、そしてソフトウェア開発者がネイティブのAppleシリコン向けにコンパイルし始めるのがどれくらい早くなるのか確信が持てなかったからだと思います。
当時は不確かでした。そして、古いソフトウェアを新しいマシンで使用できる幸せな道筋を確保したかったのです。Appleシリコンで得られたパフォーマンスの大幅な向上は誰も予想していませんでした。もしそれが分かっていれば、そもそもRosettaは必要なかったかもしれません。今では、あるからあるという状態です。
確かにそうですね。あなたが話しているような不満な顧客を避けたかったのでしょう。そして私が言ったように、私の推測では、彼らはいずれアーキテクチャからこれを取り除くでしょう。数年間は搭載し、誰もiZotopeの古いバージョンを実行しなくなった時点で、基本的に誰も必要としなくなった時に取り除くということです。それは理にかなっています。それほど大きなスペースを取るとは思えませんし...
チャットが良い指摘をしてくれました。ゲームです。ゲームは彼らがこれを維持する本当に良い理由になります。なぜなら、今彼らはMacでのゲームを推進しようとしていて、それらの多くがこれらの機能に依存しているからです。
ああ、そうですね。もし彼らがそうしたいのなら...ええ、確かに。でも私は...そうですね、ゲーム開発者はMac向けにコンパイルしませんからね。その通りです。
今その点を思い出したので、先ほど言ったことを撤回します。Rosetta 2は残ります。なぜならそれは、Appleのゲームへの中途半端な投資に完璧に合致するからです。ゲームのために特別なことはしませんが、それを可能にする機能は残すでしょう。
なるほど、そういうことですか。彼らはその路線をずっと維持していくと。Appleは顧客への投資を確約したくない時、その境界線上を歩くのが非常に上手いですからね。
さて、CPUアーキテクチャの話に戻りましょう。そこにあるものは基本的に、マイクロアーキテクチャの観点から見ると、「これらのさまざまな機能があり、これらの実行ユニットの動作方法について、常にコストがかかるわけではありません」ということです。
例えば、「Intelではこのようにフラグがセットされ、ARMではこのようにセットされる。両方を扱えるか？」というような場合です。それほどコストがかからないので、実装しました。そうすることで、エミュレーションがより簡単になり、より良い体験を提供できます。遅くて不安定なものになるよりもずっと良いですよね。
メモリオーダリングについても同様です。これは大きな要因の1つです。それを実装するのにどれだけのコストがかかったのかは分かりませんが、ISA（命令セットアーキテクチャ）の話に戻すと、メモリオーダリングはISA間で異なり、パフォーマンスに影響を与える可能性があります。
なぜなら、特定のダイサイズや特定のクロック周波数、あるいは他の指標で見た場合、より緩やかなARMのオーダリングと比べて、より厳格なIntelのメモリオーダリングを使用すると、コアが同じパフォーマンスを達成できない可能性があるからです。
先ほど言ったように、M シリーズチップでメモリモデルのオン/オフを切り替えてベンチマークを行った例があります。これは、2つの異なるメモリモデルを扱える数少ない高性能チップの1つだからこそできるテストでした。そして、2つのモデル間で約9%のパフォーマンスの違いがあったと報告されています。
これは重要な点です。ただし、これが実際を代表しているかどうかは分かりません。なぜなら、単にAppleがあまり好まない方法だから9%遅いだけかもしれないからです。そこに実装されているのが少し不安定なだけかもしれません。もしIntelのメモリモデルを採用していれば、同じくらい高速に実装できたかもしれません。
本当のところは分かりません。しかし、もし9%遅いのであれば、そこには何か理由があるはずです。おそらくARMのメモリモデルが長期的には良い選択肢で、わずかに高速または電力効率が良いなど、最適化したい指標によっては利点があるのかもしれません。なぜなら、そのような制約がないからです。
確実なことは言えませんが。ハードウェア設計者たちはおそらく意見を持っているでしょうが、口外しないでしょうね。
メモリについてはもっと長く脱線できますが、前回の動画で言ったことよりもっとひどい間違いを言ってしまいそうです。Windowsでの奇妙なメモリ分離の問題や、エミュレーションのために存在する様々なハイパーバイザー層、アプリケーション同士がお互いのメモリにアクセスできないようにする方法など...恐ろしい話です。
私の視聴者のため、そして一般的に人々が私の発言をどう見るかという観点から、自分が何を言っているのか分かっている話題に留めておきましょう。黙って、アーキテクチャの話に戻りましょう。
了解です。動画で触れた内容のほとんどをカバーできたと思います。私のメモに基づいても、あと1つだけ最後に触れておきたい点があります。
それは、あなたの動画の本来の主題についてです。実際には、「x86-64チームがIntelとAMDと手を組んで、このコンソーシアムを作って密接に協力していく」という記事を見ていたわけですよね。
その記事で指摘されていた点の1つは、AMDのスーパーバイザーエントリー拡張や、IntelのFREDなどについてでした。「これは何なのか、なぜこれをやっているのか、何が起きているのか」というものでした。
これについて少し触れたいと思います。なぜなら、これも少し興味深い話題だからです。実際にはかなり退屈な内容かもしれませんが...マイクが変な音を立てていますが、指摘しておきたいのは、これらの多くがどこから来ているのかということです。
RISCとCISCの話や、この機能が除算を持っているかどうかといった話とは実際にはあまり関係ありません。これらのコンソーシアムがx86を前進させようとしている内容は、そういったことではありません。
それは、ISAの特定の部分について「これはもっと良くできる」という明確に特定できる部分についてなのです。RISCとCISCの話や命令の削減さえも関係ありません。単にx86の歴史のある時点でなされた実装が最適ではなく、今なら改善できるということなのです。
AMDのスーパーバイザー拡張やIntelのFREDについて、両者は同じ問題を解決しようとしています。システムコール中の割り込みの処理方法や、割り込み記述子テーブルのレイアウトなどについてです。これはISAの話とは実際には関係ありません。
単に、これらの呼び出しがどのように機能するべきか、呼び出しが正確に何であるべきか、チップが割り込みを処理するルールについて、私たちはいくつかのルールが必要なのです。AMDとIntelの両方がこれを修正したいと考えています。
もしAMDが1つ導入し、Intelが別のものを導入すると、「では、WindowsカーネルチームはOSベンダーごとに1つずつ実装しなければならず、Linuxの人々も各々に対して実装しなければならない」という状況になります。それは誰の役にも立ちません。
これが彼らが話し合っている内容の1つです。「システムコール時の割り込みの処理方法や、システムコール中に割り込みが発生した場合の処理方法、割り込みの復元方法などを修正する必要がある場合、古いものが持っていた問題のない良いものを1つ作り、それに合意して前に進もう」ということです。これが彼らが試みていることの1つです。
もう1つは、Intelアーキテクチャの一部の側面が、実際にチップを設計する上で良くないということです。必要のないものがあり、それを削除できます。これは命令そのものというよりも、それらの動作方法の定義に関係しています。
例えば、Intelは何らかの理由で - x86が登場した時、私が3歳くらいでなかったら、その理由が説明できたかもしれませんが - シフト、つまり値のビットを左右にシフトする操作を定義する際、上位ビットがシフトアウトされた場合にキャリーに入るように定義し、フラグが変更されるなどの動作を定義しました。シフトに関して、フラグに影響を与える奇妙な動作がいくつかあります。
今日のプロセッサでもそれを追跡しなければなりません。シフトなどの操作を行う際、フラグを更新する必要があります。これは依存関係を作り出します。なぜなら、後で誰かがそのフラグを参照するかもしれないからです。
そのため、本来存在する必要のなかった依存関係が生まれ、スケジューリングに問題を引き起こすことになります。他にもそのような細かい問題がたくさんあり、「もう誰もこれを望んでいない、もう必要ない、これを取り除こう」という話になります。
フラグに全く影響を与えないシフト命令を作れば、コンパイラがシフトを出力する際には必ずその新しい命令を使用するでしょう。なぜなら、ほとんどの場合、実際にはフラグに影響を与えることを望んでいなかったからです。その情報を将来使用することはなかったのです。
基本的に、意図しない副作用のようなものです。CPUが処理しなければならない潜在的な将来の依存関係を作り出していますが、誰もその将来の依存関係を利用していないので、単にCPUに余計な作業を作り出し、本来可能なはずの最適化を妨げているだけです。
そういったことがたくさんあるのです。「これらを合理化しよう、誰もがこれらが間違っていることを知っている、修正して前に進もう」というわけです。コンソーシアムは、Intelが存続する限り、このようなことをより組織的に行おうとしているのだと思います。
これはx86標準や命令セットの一部ではなく、単にIntelがどのように実装したかの詳細で、それが原因で異なるアーキテクチャやそれらで動作するソフトウェアで最適ではない複雑さが生まれているのですか？
いいえ、実際にはそれは標準の一部なのです。そこが修正する必要がある部分です。標準には「これがシフト命令で、このようにフラグを変更する」と書かれているからです。そういうものなのです。AMDのプロセッサもそうしなければなりません。
その通りです。AMDのプロセッサも同じことをしなければなりません。そうしないとソフトウェアが適切に動作しません。実際にそのフラグを使用する稀なケースで。
そこで、フラグに影響を与えない新しい命令を導入するだけです。そうすれば、すべてのコンパイラがそれを出力するようになり、うまくいくでしょう。
また、命令エンコーディングをより規則的にして、デコーダーを少し単純化することもできます。これらはすべて、そのコンソーシアムで行えることであり、x86-64に対して行う必要があることです。
これはCISCとRISCの違いや、他の理由、あるいは命令の数が理由ではありません。レガシーアーキテクチャであり、非常に長い期間、後方互換性を維持しなければならなかったからです。そこにある一部の機能は、今なら改善できます。
マイクロアーキテクチャで人々が何を達成しようとしているのか、より理解が深まりました。あなたが言ったように、赤と青のパスがあって、結果として紫になったと。今や私たちは紫が何であるかを知っています。
そのため、このISAのレイアウトについて、長期的により競争力のある選択ができます。私は彼らがそれを試みようとしているのだと信じています。うまくいけばですが。
非常に理にかなっています。また、Microsoftがそのグループにいることは、ほとんどの人々がWindowsコンピュータで消費しているものに、これらの改善が実際に役立つことを確実にするために不可欠です。
また、John Carmackのような人々がそこにいることも不可欠です。なぜなら、彼はゲームやグラフィックスプログラミングがどのように機能し最適化されるかを、他のほとんどの人よりもよく理解しているからです。そのような人々が、これらの決定が私たちが書くソフトウェアに奇妙な副作用を持たないようにしつつ、実際に標準を改善するのに役立っていることを確認するのは非常に理にかなっています。
はい、そのため楽観的になる理由はあります。これがどうなるかは分かりませんが、彼らがこれを発表する前から、例えば私が話していたシフトの件については、Intelが2、3年前に提案したものです。
そのため、すでに内部で作業が進められていました。Intelは内部でこれらのことについて考え、このような提案をしていました。このコンソーシアムが、AMDであれIntelであれ、そのような改善をできるだけ早く実現する方法になることを願っています。
非常に理にかなっています。また、私は今年の初めにIntelに多額の投資をした人間として、Intelが消滅しないことを強く願っています。これは投資アドバイスではありません。これは私自身の悪い決断です。
彼らが消滅するのは良くないでしょう。私は彼らが乗り越えることを願っていますが、明らかに彼らは現在かなり厳しい状況にあります。x86-64のプロバイダーが1つになってしまうのは望ましくありません。
さて、投機実行について少し話せますか？これは私が全く理解していない部分で、とても興味深いと思います。もちろん、時間があればの話です。長く引き留めたくはありません。
いいえ、私はこういった話をするのが大好きです。唯一の後悔は、もっと多くを知りたいということです。でも、先ほども何度も言ったように、「分からない」と言っていて、それが事実なのです。本当に分からないのです。
もし手が縛られているなら、後悔するのは正当ではないと思います。あなたにはどうすることもできません。もし知ることができるなら、あなたは知っているはずです。この情報はあなたが得られる場所にないのです。
そうですね、それらの会社の1つで働くことはできますが、その場合は誰にも話すことができなくなります。そうですね、あなたは何も間違っていません。より良い選択肢がない場合、後悔することはできません。
では、公式のスライドに戻りましょう。これはAMDの公式スライドで、彼らのZen4チップ、Zen4コアのものです。投機実行とは何でしょうか？
先ほどチャットで「サイクルとは何か」と質問した人を思い出してください。電気的には説明できませんが、CPUの中の物事は調整された小さなステップで行われなければならないと言いました。
2つの数字を足し合わせるような非常に単純なことでさえ、開始から終了までにかかる時間は、先ほど話したように、フェッチされ、デコードされ、キューに入れられ、スケジュールされ、実際の論理ユニットに到達し、リタイアされるまで、14のクロックサイクル程度かかります。これらすべての段階を経なければなりません。
そのことを考えると、データセンターの例と全く同じ状況に陥ります。何かが完了するのを待つことはできません。1バイトが戻ってくるのを待って、次のバイトを要求することはできません。その時点で死んでしまいます。
ストリームのような形で物事を行わなければなりません。常にバイトが送られてきて、私は常に新しいリクエストを送り返し、それらが夜の中で交差しているのです。
CPUが同じ命令ストリームからより多くのパフォーマンスを引き出そうとする方法は、1つのことを完了させるのに14サイクルかかるという基本的な制限があるため、14サイクル待って次のことを行うことはできません。
参考までに、14サイクル待つ必要があるとすれば、それは現在のチップより50倍か60倍遅いことになるでしょう。正確には分かりませんが、そのような待ち時間が必要な場合、それは途方もなく遅くなってしまいます。そのような待ち時間は決して望ましくありません。
そのため、より高速に動作する必要があり、このダイアグラムに戻ると、デコードし、マイクロ操作を作成し、それらのマイクロ操作がパイプラインに入り、パイプラインにはスケジューラーと呼ばれるものがあります。これは基本的に、実行される準備ができるまで物事を保持するキューのようなものです。そして実行されます。
これを説明しながら覚えておいてほしいのは、「2つの数字を足し合わせてほしい」という命令を与えられた場合、その2つの数字が何であるかを知らないままパイプラインを流れなければならないということです。
なぜなら、2つの数字はまだ生成されていない可能性があるため、それらを知らずにデコードしなければならないからです。前の命令が実行されるのを待たずに、これらすべての処理を行おうとしているのを覚えておいてください。
そのため、私は2つの数字が何であるかを知りません。単にそれが加算であることだけを知っています。ここのインテジャーリネームのようなところに入ります。これらのリネームボックスが実際に行っているのは、誰が何に対して何をすると言ったのかを追跡しようとすることです。
その加算が「これとこれを足す」と言った時、その「A」と「B」は、このボックスで追跡されます。まだ誰も実際にそれらの数字を生成していない可能性があるので、それらが何であるかは分かりません。
その加算はこれらのスケジューラーの1つに入り、「A」と「B」が実際に生成されるまでしばらくそこに留まります。「A」と「B」が実際に準備できた時、私の加算が実行できる時、その処理は他の命令が生成している値を格納しているファイルからそれらの値を取り出し、加算を行うALUの1つに流れ込み、再びレジスタファイルにフィードバックされ、他の処理のトリガーとなります。
これは非常に簡単な説明で、多くの詳細を省略していますが、投機実行を理解するために本当に必要なのはこれだけです。多くの詳細を省略しているにもかかわらず、あることが分かるはずです。
ここを通ってこれらの物をキューに入れた時、何と言いましたか？数字が分からないと。なぜそうなのかが分かるでしょう。これらの値を生成した前の命令よりも前にデコードを開始しなければならなかったからです。
もっと具体的にしましょう。抽象的にならないように。例えば、「1 + num」のように、または実際にここで2つの値を取るとして、「A」と「B」を掛け合わせる - 加算を使いましょう、加算について話してきたので。
そして、それを2乗したいとします。つまり、「A + B」を取って2乗して「D」を生成し、「D」を返すという非常に単純なものです。2つの数字を足して結果を2乗するだけです。これだけです。単純で、大したことはありません。
このような非常に単純なもの、文字通り加算と乗算だけについて考えてみてください。これがこのパイプラインを流れる時、加算と乗算がここを通ってきて、加算がデコードされ、乗算はこれらの実行ユニットに到達する遥か前にデコードされることになります。
なぜなら、それらはパイプライン化されており、一緒に流れなければならないからです。その加算を最初から最後まで終えるのに14サイクルかかる可能性があり、それは長すぎます。そのため、すべてがここを流れていき、準備が整うようにしなければなりません。
加算が流れてここに留まり、乗算が流れてここに留まります。私は分かりません。最終的に加算が準備できて実行され、それが完了すると乗算が実行できるようになり、完了します。少なくともぼんやりと理解できますよね？
はい、クリックしました。ただ確認させてください。
さて、if文があるとします。何かをチェックしたいとします。何が渡されたのか分かりませんが、それが正の値かどうかを知りたく、もしそうなら「D」の符号を反転させるとします。誰が知っているでしょうか、そんなものです。
ここで問題が発生します。条件文があり、これを行うかどうか分かりません。まったく分かりません。なぜなら、これらすべての処理、すべてのマイクロ操作はおそらく、この加算を実行する前にこのパイプラインを流れるからです。
このA + Bの加算は、これらのマイクロ操作をデコードする必要がある時点ではまだ実行されていないでしょう。そのため、この否定のためのマイクロ操作は、このパイプラインを流れる物事には、問題があります。
どのマイクロ操作を送るべきでしょうか？「D = -D」のマイクロ操作を送るべきか、送るべきではないか？このブランチがどちらに分岐するかは、ずっと後になるまで分かりません。では、どうすればいいでしょうか？ここまでのジレンマは理解できますか？
先に進んで作業をしているのです。ここで投機実行が登場します。これらのチップの動作方法は、彼らは推測を行います。このブランチが実行されるか否かについて、最善の推測を行います。
このブランチに入ってこれを実行するのか、しないのかを推測します。チップのこの部分には、ブランチプレディクターと呼ばれるものが含まれています。ここにボックスとして表示されています。
そのブランチプレディクターの唯一の仕事は、実際には次にどの命令が実行されるかを推測することです。この命令ストリームを供給している時、すべては順調です。それらすべてをデコードしています。
これはIntelやARMチップに関係なく、全く同じことをしなければなりません。そのため、M シリーズには8つのデコーダーがあり、素晴らしい性能を発揮しています。毎クロックサイクル8つの単純なデコードを行っています。
突然、ブランチに到達します。困ったことに、どうすればいいでしょうか？ブランチのターゲットに行ってそれらの命令をデコードするべきか、ブランチは実行されないと考えて他の命令をデコードするべきか？
ここでの用語で言えば、このデコードをデコーダーに指示してそれを供給するべきか、それをスキップして単にこれをデコードするよう指示するべきか、どちらを行うべきでしょうか？
ブランチプレディクターの仕事は推測することです。単純に推測を行い、その推測に基づいて処理が行われます。これを投機実行と呼ぶ理由は、それが真実でない可能性があるからです。推測に基づいており、その推測は間違っている可能性があります。
このパイプラインの終わりに - ここにはあまり示されていませんが - リタイアメントバッファーまたはリオーダーバッファーと呼ばれるものがあります。様々な呼び方がありますが、より大きな命令リタイアキューなどがあります。
リタイアメント、リオーダーバッファー、何と呼ぶにしても、命令の実際の効果をリタイアする（完了させる）ものがあります。それらは最後にこのような直列キューに入り、永続的に何かを書き込もうとする場合、その効果が完了したと見なされます。
そしてここに到達した時、そのバッファーはブランチプレディクターが推測した内容が実際の値と一致するかどうかを確認します。ブランチプレディクターがCが0より大きいと推測した場合 - 実際にはブランチプレディクターはどこに行くかを推測するだけですが、この説明のために - もしブランチプレディクターがCが0より大きいと推測したが、ここに到達した時に0より大きくなかったことが判明した場合、それは誤予測です。
その時点で、リタイアメントバッファーはここと間のパイプラインからすべてのマイクロ操作をフラッシュし、パイプラインから完全にフラッシュして最初からやり直さなければなりません。
これを分岐予測ペナルティと呼びます。これらのスケジューラーに詰め込まれ、準備できていたすべてのマイクロ操作が間違っていたことが判明したため、それらをフラッシュして新しい場所から再開しなければならないという追加のコストです。
このことがスケジューラーに十分な量を供給して再度動作させるまでの時間が、分岐予測ペナルティです。これが、誤予測された分岐が正しく予測された分岐よりもはるかにコストがかかる理由です。
正しく予測された分岐は基本的に無料ですが、誤予測された分岐は非常にコストがかかります。理解できましたか？
はい、非常に理解できます。
そうですね、投機実行と呼ばれるのは、まさにそれが理由です。これらの操作を実行したいと推測しているのですが、それが真実でない可能性があります。
サイドチャネル攻撃などが発生する理由は、チップ上でこれらの投機的な処理が多く行われており、時として本来は起こってほしくない観察可能な効果を持つことがあるからです。
SpectreやMeltdownなどがそうです。CPUは時として投機的にメモリを要求し、この分岐予測を行います。これらはすべて投機的です。これらの投機的な処理の一部には観察可能な効果があり、セキュリティにとって非常に危険な場合があります。
なぜなら、タイミングの統計を見ることで、攻撃者がこれらの効果の一部を観察できる可能性があるからです。カーネルで実行されるような、より高い特権レベルで発生する可能性のあるものです。
キャッシュプローブのタイミング特性や、誰かが実行に要する時間などを観察することで、アクセスするべきでないものにアクセスできてしまいます。これらの投機実行の一部を見ることができ、情報を漏洩させることができてしまうのです。そのためにこのような問題が発生します。
つまり、投機実行には2つの側面があります。1つは、これは常に発生しており、そのために分岐予測ペナルティが発生するということです。もう1つは、サイドチャネル攻撃という概念で、これらの投機実行の効果が実際に観察可能になってしまう場合があるということです。
リタイアメントバッファーがこれらの投機的な処理が決して起こらなかったように見せようと懸命に努力していても、実際には起こっていたのです。
これは私にとって非常に有益な情報で、いくつかの誤解を解消してくれました。分岐予測の一部として、複数の可能性のある分岐を実行してみて、正しい方を解決すると思っていました。最も可能性が高いと思われる方を推測し、間違っていた場合は巻き戻すという事実は、私の理解を根本的に変えました。この訂正に感謝します。
はい、その通りです。実際には1つだけを実行します。少なくとも主流のCPUでは、両方の側を試みるCPUについては聞いたことがありません。なぜなら、彼らは主にそのブランチプレディクターを本当に優れたものにすることに焦点を当ててきたからです。
彼らは常にそのブランチプレディクターの改善を試みており、非常に稀にしか間違わないようにしています。また、投機実行について、リタイアメントバッファーについて説明した方法では、そのような印象を与えてしまったかもしれませんが、その印象を残したくありません。
投機実行の処理は、ここに留まっているだけではありません。アウトオブオーダーCPUでは、準備ができたものは何でも実行できます。もしこの否定をこの計算の直後、これを見る前に実行できると判断した場合、実行することができます。
これらの結果はすでに計算されており、単にそのリタイアメントバッファーで待機しているかもしれません。つまり、保留中のマイクロ操作だけでなく、完了したマイクロ操作もフラッシュしなければならないのです。
理解できました。すぐに浮かぶ質問は、開発者として、どの分岐が最も可能性が高いとプロセッサに示すことは可能でしょうか？
以前は、分岐予測ヒントはより一般的なものでした。古き良き時代と言えばいいでしょうか。10年から15年前のことかな。正確には覚えていません。
言えることは、あなたが話しているものは確実に存在していました。分岐予測ヒントは100%存在する機能で、今日でも存在します。現在のアーキテクチャが分岐予測ヒントから得られると期待している効果については、私の理解では非常に少ないです。
今では本当に優れたプレディクターがあり、分岐予測ヒントについてはほとんど言及されなくなりました。今日では、プレディクターが十分に優れているため、それはもはや価値がないのです。実行時に伝えられることは、ほぼ即座に把握されます。
実際には、ヒントの方法さえ知らないようなことを見ています。パターンベースの要素を見ているのです。例えば、流れてくるデータに基づいて、「これは2回実行され1回スキップされるパターンだ」というように検出し、それに対応するわけです。
今日では非常に洗練されており、ヒントは優れたプレディクターが登場した時点で時代遅れになったと思います。チャットの皆さん、私がReactコンパイラについて話を脱線させないようにするのがどれほど大変か分かりますか？でも実際に同じことなのです。そしてこれは痛いです。
簡単に説明すると、Reactはより効率的になろうとしています。Reactのコードをより効率的にする重要な点の1つは、メモ化です。Reactが何度も何度もチェックする必要がないことを知るためです。
コンポーネントから関数まで、あらゆるものをメモ化することです。歴史的に、私たちはそれらのメモ化スクリプトを書いてきましたが、それは遅いものでした。Reactコンパイラは変数とそれらがどこに渡され、どこでインスタンス化されているかのグラフを作成することで、すべてを自動的に行います。
そのため、すべてがメモ化されますが、それは予測的であり、ベストを尽くしています。以前は自分でuseメモの呼び出しを書くことができました。私たちは何かが更新されるべきかどうかをReactに伝えなければならず、デフォルトでは単に更新されていました。
今では、それを学び直す必要があります。Reactコードにヒントを入れることをやめなければなりません。なぜなら、実際にはそれは私たちのコードを悪くするからです。私たちが管理し構築しているロジックに余分な複雑さが加わるのです。
システムは私たちと同じくらい上手くできるだけでなく、しばしばより上手くできます。なぜなら、私たちが気づかないようなことまで気づくからです。そして、私たちのコードをよりシンプルにすることができ、シンプルなコードはしばしばこれらのアーキテクチャで処理しやすいのです。
私は特定のことについては明らかに何も知りませんが、ここでも同じ側面が働いているのだと推測します。基本的にデータは多くの場合動的なので、実行時にCPUまたはこの場合メモ化機能は、プログラマーよりも多くの情報を持っています。
プログラマーは実行時にどのようなデータが与えられるか正確には知らないからです。CPUはそれを見ています。実際の分岐パターンを見ているのです。Reactのメモ化機能も同様に、その時点で流れている実際の使用パターンを見ているはずです。
技術的には、十分に優れていれば、あなたよりも優れているはずです。なぜならデータを持っていて、あなたは持っていないからです。
そうですね。そして、それが今日の高性能CPUの状況だと、ハードウェアアーキテクトは言うでしょう。彼らの分岐プレディクターは、単にヒントを使用する場合と比べてかなり優れる傾向にあります。
その通りです。これがどれほど似ているかは奇妙です。Reactコンパイラの面白い点の1つは、godboltで見せてくれたようなツールを持っていることです。Reactコードを入力すると、コンパイルされたReactコードが出力されます。
特別なフラグがあり、変数をインライン化して後で使用できるようにする方法を、渡し方に応じて決定できます。書きたくないようなコードに見えますが、少なくとも1行ずつ読んでそれらの最適化と予測を見ることができます。
残念ながら、ここではそれができません。C言語のコードを与えられた時に、どのパスが最も可能性が高いと考えているのかを見る方法は、少なくとも簡単にはありません。少なくともJavaScript の世界ではそれが可能で、これらの理解と価値の理解に大いに役立っています。
繰り返しになりますが、私たちウェブ開発者やソフトウェア開発者、特にアプリケーション開発者は、より効率的なソフトウェアを作り、より良い構築ブロックを提供するために、これらのことを理解する必要があります。
これらのことを理解するウェブ開発者であることは、ウェブの世界全体にとって大きな価値を付加する可能性があると思います。
その通りです。実は信じられないかもしれませんが、マイクロアーキテクチャレベルでも、分岐予測の観察をある程度得ることができます。実際にチップ上にカウンターがあり、実行パス上の2点間で正しく予測された分岐と誤予測された分岐の数を教えてくれます。
私たちが実際に行っていることの1つは、この特定の処理に対して分岐プレディクターがどれだけ上手く予測しているかを見ることです。それ自体が非常に興味深いことです。
それは非常に面白いですね。チャットで誰かが、godboltにもこれを可視化する方法があると言及していました。そのツールは信じられないほど素晴らしそうです。異なるループや予測を可視化できるようです。
具体的な説明はありませんでしたが、godboltはこの予測を表示できるということでした。ただ、何を表示するのかは分かりません。予測はデータに基づいているので、実際には分からないはずです。
そうですね、私も分かりません。しかし、多くのツールがあります。分岐ランキングを可視化できるようです。また、LLVM MCAがあり、分岐とは別に、コードがどのように実行されるかを見ることができます。
これはLLVMに組み込まれている機能ですが、分岐がどのように予測されたかを実際に知ることができるのは、カウンターを読み取ることによってのみです。そして、CPUごとにも変わります。
これは非常に面白い内容ですね。他に私が間違っていて、取り上げる価値のある特定の点はありますか？それとも質疑応答に移りましょうか？
質疑応答に移りましょう。ほぼすべてをカバーできたと思います。一時点で、Appleがチップにビデオ処理を追加し、x64側がそのオプションを考えていなかったという話をしましたが、それについて触れる必要があるかもしれません。明らかにそれほど有用ではないかもしれませんが。
はい、それについて私はある程度間違っていたと思います。AppleはCPUに特定のビデオエンコード用ハードウェアを搭載することを本当に強く推進した最初の企業の1つだと思いますが、それが間違っているなら、詳しく見てみましょう。
では、それについて手短に触れましょう。これは重要だと思います。なぜなら、区別を付けたかったからです。M シリーズチップはCPUではないということを覚えておく必要があります。今日では一般的にAPUと呼ばれるものです。
これは、CPUとGPUが1つのダイに統合されているということです。複数の種類のプロセッサが1つにまとめられているのです。実際...M シリーズのダイショットを持っているでしょうか？分かりません。
クイック確認ですが、APUという言葉をよく耳にするようになりました。APUはCPU + GPUよりも高レベルなものですか？私の理解では、APUはCPU + GPUでしたが、APUはCPU + 他のもの（メモリなど）なのでしょうか？
私もその混乱を共有します。APUは、CPUとGPUが同じダイ上にある場合に使用する用語だと思います。そうですね、通常はより広い用語で、潜在的にそれ以上のものを含む可能性がありますが、教科書的な定義があるかどうかは分かりません。
私が言いたかったのは、M シリーズチップは一種のオールインワンプロセッサクラスターだということです。どう考えるかにもよりますが、Zen4コアやクラスター、あるいはZen4ダイ上のCCDについて考えると、それは単にデスクトップチップの処理部分で、GPUが独立したカードとして接続されるのとは非常に異なるものです。
この2つの違いを指摘しようとしていただけです。システムオンチップ（SoC）に明確な定義があるかどうかは分かりません。多くの文脈で使用されています。APUについては、AMDのマーケティング用語としてしか聞いたことがないと思います。
そうですね、SoCがより一般的な用語で、APUはAMDの用語だと理解していました。チャットで誰かが同じことを言っていました。この用語は避けておきましょう。定義が分かりませんから。
M シリーズのダイショットを見てみましょう。これが実際のチップです。AnandTechのラベル付けによるものです。また、ハードウェア企業はラベル付きのダイショットを提供しないことを覚えておいてください。決してそれは得られません。
ダイショットを得られるかもしれませんが、それさえも正確でない可能性があります。芸術的な描写のダイショットかもしれません。しかし、彼らはそれにラベルを付けました。これがAnandが付けたラベルで、これがどのように配置されているか見ることができます。
これは私が思うにM1で、見てみると、これらの小さなタイルの1つ1つがGPUプロセッサの1つです。これらはGPUコアです。これはおそらくバックボーンで、キャッシュを持つメモリのようなものだと思います。分かりません。
GPUの部分がここにあり、これらが強力なプロセッサです。これはおそらく中央のキャッシュで、これらが4つのコアタイルです。私は推測していますが、このような記事を十分読んできました。
これは外側にありますが、実際にはこのボックスで、ニューラルプロセシングユニットがここにあります。そして効率的なコアがここにあります。外側ではなく、この部分です。
この部分はラベルが付いていませんが、ビデオエンコード/デコードがここにあると思います。私の理解では...私はAppleのビデオエンコーディングのオタクで、以前ハッキントッシュを使っていた時に深く関わっていました。
求めていたパフォーマンスが得られず、AfterburnerアーキテクチャとAppleがビデオエンコード/デコードのために行ったことを発見しました。これはGPUと重なる部分がありますが、同じではありません。
ニューラルエンジン領域かどのかにAfterburnerチップの後継があり、それはh.264/h.265のエンコード/デコードだけを行うと理解しています。その通りです。
私はここでそれを示していますが、このダイショットにはラベルが付いていないからです。ここに箱があるはずです。おそらくここら辺にあると思います。理解できました。
では、Zen4 APUのダイショットを見てみましょう。ここにコアがあります。より大きなコアです。これも再びコミュニティによってラベル付けされています。常にコミュニティによるラベル付けです。
TwitterのBus Alexiという人によるものです。クレジットを与えたいと思います。これを見ると、「はい、ここにキャッシュがあります。4つのCコア、より小さなコアがあります。Zenでも大小のコアがありますが、完全に同じではありません。
Zenの大小構成は少し異なりますが、コアのよりコンパクトなバージョンを持っています。これらが大きなコアで、これらが小さなコアです。ここに再びキャッシュがあり、ここにGPUコアがあります。
特定の方法でラベル付けされていませんが、何らかの形でタイル状に配置されているはずです。ここにメディアエンジンがあり、これがビデオ部分でエンコードとデコードを行います。
つまり、基本的にAppleと他社で全く同じです。大きなコア、小さなコア、キャッシュ、メディアエンジンでビデオのデコードを行います。Appleとそれ以外で実質的な違いはありません。
M シリーズチップにはあるがZenチップにはないように見えるのは、SoC用ではないZenチップを考えているからです。通常、PCではこれはGPU上にあります。AMDのGPUのダイショットを見ると、通常VCNとラベル付けされています。
AMDのGPU上にビデオエンコード/デコードがあります。なぜならそこが最も効率的な場所だからです。実際にビデオを出力する場所だからです。しかし、M シリーズに相当するZen4 APUを見ると、GPUとCPUが1つのダイに統合されており、PCでもAppleでも全く同じことが当てはまります。
専用のエンコード/デコードが全く同じように存在するのです。
私の見方を修正させてください。これは良い文脈で、私の説明が明確でなかったことは確かです。興味深いと感じた点は、APUがアーキテクチャが定義された後に追加されたように感じたことです。
AMDのフラッグシップチップ、毎年プッシュする最上位モデルは、新しいCPUと、ATIを買収してからは新しいGPUでした。これらは2つのトップライン製品でした。APUはより大きく宣伝されるフラッグシップ製品ではなく、特定のニーズ、通常はラップトップ向けに、それらのアーキテクチャの最高の部分を凝縮したものでした。
私が興味深いと感じたのは、フラッグシップチップにメディアエンジンが搭載されたのを初めて見たことです。
はい、その唯一の理由は、彼らの製造戦略が独立したものを出荷しないことだったからです。つまり、彼らには選択の余地がなかったのです。他にどこに置くことができたでしょうか？
通常、デスクトップではCPUとGPUを分離します。なぜならGPUに専用の高性能メモリを持たせたいからです。それはCPU側とは別で、PCユーザーが交換できるようにしたいなど、様々な理由があります。
Appleにとっては単に、競争力を持つためにそれが必要だったのです。ビデオエンコーダー/デコーダーを持たないわけにはいきません。すべてのPCがそれを持っているからです。APUのような統合ダイ上にあるか、GPUにあるかのどちらかです。
Appleはビデオ分野で競争力を持つためにそれを持たなければならず、システム内に実質的に存在する唯一のチップに搭載する必要があったのです。
これはAPUやそのマーケティング用語だけの話ではありません。Skylake時代のIntelを見ても、ラップトップ向けのIntel統合グラフィックスには、すべてビデオコーデックが搭載されていました。
これは単にビデオエンコーディングの性質です。特殊な目的の機能を作って高速化できるのです。誰もが行っており、低電力で行いたいと考えているからです。元々は、より高い解像度を処理したかったのにCPUが十分な速度で処理できなかったからです。
今では十分に速く処理できます。しかし今日でも、CPUで処理したくない理由は、これらの専用ASICの1つに機能を組み込む方が、はるかに低電力で済むからです。そのため、今でもそうしています。
それは理にかなっています。私は未だにAppleのメディアエンジンでできることに驚いています。他社も追いついてきていますが、10〜15ワットの電力しか使わない小さなMacBook Airで、2つの4Kストリームをリアルタイムでエンコードできるなんて、当時は前代未聞でしたし、今でもすごいことです。800ドルの中古MacBook Airだけで、私の仕事は全てできてしまいます。
実際の結果に注目する必要があります。そこに至るまでの細かい部分は、重要でないか、私が大きく間違っていたかのどちらかです。これは、こういった事柄を説明する上で本当に有益です。Appleが気にしていたのは、どこにこれを置くかということではありませんでした。彼らのアーキテクチャの設計が革新的だったわけではありません。単に、当時は他の誰も試みていなかった特定の目標があり、それを達成したのです。そして今では、技術的な実装方法に関係なく、他社も同様のパフォーマンスレベルを目指しています。
そして、私はこの特定の事例に詳しくはありませんが、Appleは単一の統合されたプラットフォームプロバイダーであることから大きな恩恵を受けているのだろうと推測します。つまり、「今後2年間は全てのMacにこの特定のMシリーズチップが搭載される」ということが分かっているので、エンコードパイプラインを作る際に、そのチップを最大限活用できるということです。
対照的にPCを見てみると、「どうやってそれを実現しようか？ドライバーが必要だ。Zen4 APUなのか、差し込んだNVIDIAの独立グラフィックスなのか、それともIntelの統合グラフィックスのメディアエンコーダーなのか」といった具合に、最小公分母的な対応が必要になります。全てのドライバーがインストールされ、正しく動作し、全て活用できるようになっていることを確認しなければなりません。
だから私が思うに、Appleはシリコン上に何があるかを知っているので、エンコードの際にそれを最大限活用できる、というのが彼らの強みの一つなのでしょう。管理すべきエコシステムがないからです。間違っているかもしれませんが、それは彼らにとって大きな利点だろうと思います。
実際、BlackmagicはWindowsでのDaVinciのGPUアクセラレーテッドエンコーディングに200ドル請求しています。お金を払わなければならないんです。
とても役立ちました。本当に明確になりました。他に何かなければ、質問の時間にしましょう。よく「分からない」と答えることになると思います。ハードウェアエンジニアがここにいてくれたらいいのにと思います。
最初の質問です。Computer Enhanceの次のエピソードはいつ公開されますか？パート4を楽しみにしている人が多いですね。
パート4の最初の部分は先週公開されました。次は明日か今週中には出る予定です。とても楽しみです。
Intelの最新プロセッサの最近の不具合と安定性の問題について、何か見識はありますか？製造の問題なのか、アーキテクチャに問題があるのか。もう一つ付け加えると、AMDより1%でも良い結果を出すためのベンチマークレース的な要素はありますか？
Raptor Lakeの不安定性について、13世代と14世代でしたっけ、名前は覚えていないのですが、色々な説を聞いています。正直よく分かりません。
Intelの曖昧なプレスリリースや、バグや不安定性の問題を発見した人々の報告で見てきたことをお話しすると、過去10年間のIntelとAMDの状況を見てみましょう。
Intelは自社でチップを製造していて、世界最高のプロセス技術を持っていました。これは彼らが主要なチップメーカーだった理由の一つで、x86-64の独占だけが理由ではありませんでした。彼らの製造技術は世界一だったのです。
AMDはこの面で苦戦していました。AMDには独自のファウンドリがありましたが、後にGlobalFoundriesとして分社化され、現在は別会社になっています。これが問題でした。AMDは外部製造に切り替え、ファウンドリ事業を分離し、TSMCに製造を委託することにしました。
TSMCは信じられないほどの成果を上げ、毎年Intelに近づき、そして追い越しました。Intelには10ナノメートルと呼ばれるプロセスがありました。もちろん、これらのナノメートルという単位は実際には何も意味していません。ナノメートルでの測定は、もはや実際には何も測定していない測定コンテストのようなものです。
その数字は本当に多くを語らないので問題になっています。今ではTSMCのN5ノードなどと呼ばれていますが、当時、TSMCはIntelよりも優れたチップの製造を始めました。IntelのファウンドリではIntelの10nmプロセス技術がうまくいかなかったからです。
残念ながらIntel は、ファウンドリに関して本当に厳しい状況に陥りました。長い間、軌道に戻ることができませんでした。そのため、実質的に同じプロセス技術から、その後わずかな改善を加えただけで、より多くのパフォーマンスを絞り出さなければならないという奇妙な状況に陥りました。
一方でTSMCは着実に前進を続け、プロセス技術を改善し続けています。そのため、AMDは優れた設計能力を持っていたので、より競争力のあるチップを作り続けることができました。チップの設計は常に優れていたので、今や優れたプロセス技術も手に入れ、単純に優れたチップを作れるようになったのです。
この状況のために、Intelは本当に競争力のあるチップを作るには、チップの消費電力を大幅に上げる以外に方法がありませんでした。
繰り返しになりますが、電気技術者に聞かなければ、これらの電力のトレードオフがどこから来るのかは分かりません。しかし、AMDがIntelと同等のベンチマーク結果を出しながら、半分の電力しか消費していないという状況が見られました。さらにその後、3分の1の電力でベンチマークが同等になり、Intelの消費電力は上がり続けました。
AMDは「120ワット、時には90ワット、65ワットのパーツで競争できる」という具合に、パフォーマンスを上げながら消費電力を下げていったのです。信じられないことです。
実際の例を挙げましょう。最近、ストリーミング用に14世代のマシンを組み立てました。TDPは125ワットですが、デフォルトでどれくらいの電力を消費していたと思いますか？
350ワット？
その通り、350ワットです。電源ユニットがうなり始めました。
これが現状です。より古いプロセス技術で、大幅に改善された設計もないまま、性能を競争力のあるものにしようとして、途方もない量の電力を使用していたのです。
電気技術者の言うように、これらのチップに任意の量の電力を流すことはできません。全てがうまくいかなくなります。私の理解では、それが本当に起こっていたことでした。チップの特定の部分の電圧が超過しないようにする電力管理の問題でした。
多くの人がリングバスについて言及していました。リングバスはチップの各部分間の通信を行うものですが、特定の電力レベルを扱えなかったようです。
私の専門分野ではないので詳しくは分かりませんが、聞いた話によると、Intelは競争力を維持するためにこれらのチップに過剰な電力を流そうとし、何かを見落としてしまったようです。チップが過熱したり損傷したり、誤った結果が出たりしないように、電力を非常に慎重に管理しようとしましたが、何かを見落としてしまい、長い間その原因が分からなかったようです。最終的には修正されたはずです。
それが私の理解とほぼ完全に一致します。Gamers Nexusの動画から思い出した追加の詳細があります。製造に関して、水が浸入して、推奨負荷では問題なかった部分が、全てのマザーボードが crazy wattageで動作し、Intelもそれを奨励していたため、小さな部品の腐食が過剰な電力を流すとより激しく故障する可能性があったということでした。
少なくともIntelの説明によると、それは初期の問題で解決済みで、そんなに多くのチップには影響していないとのことです。Intelは、Gamers Nexusが言及した通りかどうかは明言しませんでしたが、製造上の欠陥があったことはほぼ認めています。
しかし、それは一部のチップの比較的小さな問題に過ぎず、その欠陥が修正された後でも、チップは適切に電力を制限できていませんでした。リングバスが原因かもしれませんが、誰も特定できなかったようです。そのため、製造上の欠陥がなくてもチップは故障し続けていました。
マイクロコードについて覚えているのは、時々パイプに full wattageを送って、ある部分が故障する可能性があったということで、それが現在プッシュされている更新の一つです。
私のマシンの一つで面白いことがありました。Twitterでも見たかもしれませんが、Dellが去年のブラックフライデーあたりで大幅な割引をしていて、13700非K、16GBのRAMなど、かなりハイエンドなDellデスクトップを490（4090）込みで900ドルで手に入れました。4090の小売価格だけでもそれ以上するのに、マシン全体をその価格で入手できました。
使用済みですか？
いいえ、新品です。たくさんの割引があり、最近の購入でDellのクレジットもあったので、4090搭載の完全なデスクトップを手に入れることができました。DellのGPU製造は実際にとても良いので、4090を別のマシンに移して、別のGPUを入れました。今はリビングルームPCとして使っています。
Dellのものなので、OEMが最近何をしているのか興味深いので、標準のオペレーティングシステムのままにしていました。Dellの強制的な推奨アップデートがあり、実行するまで消えませんでした。保証の返品を減らしたいからでしょうね。
そうですね。他に何も言うことがありません。本当に悪い状況で、修正されたかどうかは分かりません。聞いた話では、マイクロコードの更新で完全に修正されたそうですが、以前に高すぎる電力を流してしまった場合のダメージは元に戻せません。壊れたチップは修復できませんが、これ以上の破損は防げます。Intelはこれらのチップの保証を4年に延長したと思います。
状況を考えると、うまく対処していますが、ここに至るまでの道のりは大変でした。ストリームで1、2回話したことがありますが、普通は誰も気にしません。でも今回はこういうことについて語れて嬉しいです。
そういえば、Linus Tech Tipsの人たちと話したことはありますか？
いいえ、Linus Tech Tipsの人たちとは全く知り合いではありません。
LukeとはとてもよしくしていますOし、彼らのことが大好きです。将来、もしよければ紹介させていただきたいです。彼らはあなたの知見について話を聞くのを楽しみにすると思います。
もちろん、喜んで誰とでも話をします。ただし、ハードウェアエンジニアではないので、できることには限りがあるという但し書きは付きます。このような高レベルな会話は、何人かの人には非常に役立つと思います。個人的に、その紹介をさせていただきたいと思います。通常、こういった話はLukeとしかしません。
彼らはこういうことが大好きで、最も届きにくい層であるPC gamersの誤った思い込みを正すのを手伝ってくれる人たちです。
分かりました。何か明確にできることがあれば、常に喜んで手伝います。役立つと思うことがあれば、その紹介を喜んでさせていただきます。
追加の質問を探しています。誰かがW3C標準について、つまりウェブ標準についてどう思うか尋ねていますが、もし意見があれば聞かせてください。
彼らは貧弱です。他に言うことがありません。基本的なことさえできないような大量の仕様を生成しています。最近のアップデートでようやくブラウザで要素を移動できるようになりました。万歳ですね。
良くありません。とても良くありません。それらの仕様が本当に良いものであれば、ウェブはずっと良くなっているはずです。それだけです。
実際に興味深い考えがあるかもしれない質問があります。誰かがOpenGLが実質的に終わっていると言及し、WebGPUが疑似的な代替として、そしてグラフィックスプログラミングの入門としても、また将来的な標準的な到達点としても、どう思うか気になっています。
こう言いましょう。グラフィックスAPIの時代は永遠には続かないと思います。グラフィックスAPIが生まれた経緯を見ると、プログラミングしていたハードウェアが非常に特殊化されていたからです。基本的に、APIを通じて全ての細かいことを具体的に指定する必要がありました。これらのテクスチャ、これらの三角形、三角形に使用してほしい投影行列、そしてそれが投影行列であることなど、全てです。
それは全て、ハードウェアがそれらの具体的なことを知る必要があったからです。なぜなら、それが実際にハードウェアがすることだったからです。このテクスチャを特定の方法でこの三角形のテクスチャとして使用し、云々という具合に。
今日では、一部のレンダリングエンジンでは、ラスタライザーさえ使用しないところまで来ています。深度プリパスなどには依然として使用されますが、パイプラインを押し下げるよりも効率的だからコンピュートシェーダーで独自のラスタライザーを書いています。バインドレスでは、GPUがまだ正確に何であるかを知らされていないメモリアクセスを行っているなど、そういったことが全て起こっています。
プログラマーが本当に望んでいるのは、CPUをプログラムするのと同じようにこれらをプログラムすることです。コードを書いて、実行してもらうだけです。テクスチャが何かを指定したくありません。これらのものが何であるかを指定したくはありません。
残念ながら、これらのメモリアクセスパターンを最適化する方法のために、まだいくつかの制限があります。避けられない側面がまだいくつかあります。例えば、これがテクスチャであることを伝えることを完全になくせるかというと、必ずしもそうではありません。そういった部分はまだありますが、全体として、APIが何であるかはますます重要でなくなり、コードが何であるかがますます重要になってきています。
つまり、シェーディング言語や配布する中間表現が重要になってきています。例えば、WebGPUはSPIRVを採用しなかったと思います。推奨されたにもかかわらず採用せず、独自のテキストベースのシェーディング言語を作りました。それで合っていますか？SPIRVが含まれていないことは知っていますが、WebGPUでシェーダーをどうエンコードするのかは知りません。独自のシェーディング言語を作ったと思います。間違っていますか？誰か教えてください。WebGPUをそれほど詳しくフォローしていないので。
WebGPUシェーディング言語W3Cワーキングドラフトの文書を見つけたので、はい、彼らは独自の言語を作りました。
基本的に言いたいのは、まず、他の人のストリームでは以前ほどネガティブにならないようにしています。特に...いや、私のは好きなだけネガティブになっていいですよ。でも他の人のストリームでは、自分のストリームでさえ、以前ほどネガティブにならないようにしています。
しかし、世界中の誰も新しいシェーディング言語を望んでいませんでした。開発者にとって、このシェーディング言語で書くのか、あのシェーディング言語で書くのかといった問題に対処しなければならないのは、すでに大きな問題です。両方のプラットフォームで配布する必要があるので、一方から他方へ変換するものか、両方に出力する言語を作るか、といったことが必要になります。誰もこれを望んでいません。
なぜJavaScriptのようなもので書くのでしょうか？一度書けばどこでも動作するからです。WebGPUの問題は、計画は何なのかということです。ウェブ開発者だけがウェブ用に書くものなのか、その場合は独自のシェーディング言語を作ることはそれほど大きな問題ではありません。希望としては、かなり似たものにしたはずです。しかし、それならWebGPUはOpenGLに取って代わることはありません。ウェブ向けの配布に特化したものだからです。
しかし、WebGPUをより広く使用し、一般的にプログラミングするものとして考え、そのシェーディング言語を全てに使用し始めるという考えなら、開発者はそれに移行するのでしょうか？移行する動機は何でしょうか？3D開発のほとんどはウェブを全く気にしません。ウェブはほとんどの場合、2Dメディアです。これにどれだけ関心を持つでしょうか？それほど多くないと思います。
シェーダーが本当に気になるなら、WebGPUに移行することがどれだけ魅力的でしょうか？あまりないでしょう。予測を立てることはできませんが、WebGPUは実際には何も提供していません。誰も望んでいなかった新しいシェーディング言語です。時間とともに標準として普及するため、採用を強いられるかもしれませんが、誰もこれを楽しみにしているとは思いません。誰もこれを望んでいません。
私たちが望んでいたのは、統一された、例えばHLSLを選んで、それをどこでも使うということでした。それが私たちが望んでいたことですが、そうはなりませんでした。
面白いことに、ある意味でウェブはJavaScriptが一つの言語と標準であるという点で良いのですが、今では外部に存在する問題に対して新しい言語と標準を発明しています。
チャットの何人かから情報を得ましたが、apparentlyAppleがSPIRVの大きな障害だったそうです。その通りですね。Appleはウェブを後退させ続けています。AppleはWebGPUを完全に台無しにしました。最初の推奨は、VulkanのようなものでSPIRVのような標準的なものを採用し、同じシェーダーを配布できるようにすることでした。しかし、いいえ、Appleが入ってきて...これは推測ではありません。気になったので実際に議事録を読み、Appleの代表者が「それはしない」と言うのを見ることができます。
Appleのウェブ標準の件では何度も経験があるので、驚きませんが、痛いですね。彼らがそうしなかったことは本当に残念です。本当に最悪です。
最後の質問です。政治から指導者、製造に至るまで、全ての変化の中で、現在のTSMCと比べてIntelをどう評価していますか？追いついているのか、まだ遅れをとっているのか、そしてそこに期待できる未来を見いだせますか？
Pat Gelsingerがやっていたことについての私の意見は、多かれ少なかれ正しいことをしていたということです。Fortune 500企業の運営については本当によく分かりません。でも彼はエンジニアリングのバックグラウンドを持ち、ファウンドリを軌道に戻すことに焦点を当てていましたが、それは大きな問題です。
そういったものの資本支出は天文学的です。私たちには本当に理解できないようなものを管理しようとしているのです。年間200億ドルを物理的なものを構築するために効率的に展開することを心配したことはありません。少なくとも5年、おそらくそれ以上の結果が出ないような物理的なものです。そのレベルの投資は想像を絶するものです。
この規模でCPUを製造することは、人類が今まで行った中で最も難しいことの一つだと言われており、一般的にそれは真実です。彼らが行っているスピードでこれらのことを行うのはほとんど不可能です。
プロセスについて読み、同じ液滴に複数回レーザーを当てて光を散乱させる奇妙なことについて読むと、その光は波長が小さすぎて鏡で反射できないため、特殊なものを通過しなければならないなど、完全に作り話のように聞こえます。プロセス全体が作り話のように聞こえます。
外部の観察者として、内部の知識は全くありませんが、Pat Gelsingerは与えられた悪い状況の中で最善を尽くしていたように思えます。彼が成功したかどうかは分かりませんが、他に何ができたのかは分かりません。
彼が追い出され、代わりにCFOやマーケティング担当者のような人々を起用したのは...誰が就任したのか覚えていませんが、これはエンジニアリングの問題を解決しているのです。マーケティングでは何もできません。最先端のファウンドリがなければ、マーケティングするものは何もありません。
ファウンドリを手放して、今後全てをTSMCで製造するとしたら、Intelの付加価値は何でしょうか？AMDよりも競争力のあるマイクロアーキテクチャを設計しているわけではなく、実際、現在はそれほど優れていないように見えます。ファウンドリでなければ、価値は何なのでしょうか？分かりません。
もし何かあるとすれば、以前よりもずっと不安です。あなたはどう感じていますか？
分かりません。私の直感では、ファウンドリのスピンオフと新しい投資の結果を見るまでは分かりません。うまくいくか、全くうまくいかないかのどちらかで、それを予測することは不可能です。
アーキテクチャがしっかりしている2社は、AMDとAppleです。Appleは自社のチップを販売することに興味がありません。Appleチップを搭載したNintendo Switch、長年の夢です。AppleがNintendoを買収しなかったことにまだ腹を立てています。それは基本的に全ての関係者にとってより良かったはずです。
しかし、それはさておき、Intelはファウンドリがうまくいかなければ優位性がありません。それらの投資が本当に良い結果を生まない限り、彼らが成功するのは想像できません。彼らの最善の賭けは、関税がTSMCの製造業者全てを苦しめ、そこから優位性を得られるかもしれないということです。
しかし、GPUの実験は大きく失敗しました。心が痛みます。もっとうまくいくことを本当に期待していましたが、大きく失敗してしまいました。ファウンドリがうまくいかない限り、他の優位性はないと思います。
そうですね、私の言ったことと同じ線上にいるように聞こえますね。ファウンドリは非常に重要です。指導者の交代についてはどう感じていますか？指導者の交代は、もしかするとファウンドリの部分を軽視しているように見えます。それが私を不安にさせているのですが。
古い指導者と新しい指導者についてほとんど理解していないので、意味のあるコメントはできません。
製品の発売とこれまで聞いてきた計画に基づいて純粋に判断してきました。CEOの具体的な決定や考え方については理解していません。AMDのSuについては多くのことを知っていますが、Patが何をしてきたのかについては何も知りません。
そうですね、とにかく私たちにはそれほどの洞察はありません。そこにいない限りは分かりません。
SuがTime誌の今年の人物に選ばれたのを見ました。彼女はそれに値します。AMDでのLisa Suの実績を見ると、かなり驚異的です。AMDの株に250%のリターンがあり、とても満足しています。
11年間AMDのチップを買っていませんが、Intelのチップを買うたびに、同じ金額をAMDの株に投資していて、それはとてもうまくいっています。プログラマーとして、Zen4は本当に気に入っています。Zen5も持っていますが、別のマシンにあるためほとんど使っていません。開発マシンはゆっくりと変更するので。でも、それらは本当に素晴らしい製品です。大好きです。
そして、彼女の意思決定の実績を見ると、本当に素晴らしいものでした。チップレットとInfinity Fabricに全てを賭けること、外部のファウンドリを使用することを決めること、これら全ての決定は、私の理解では、ほとんど、もしくは全てがLisa Suの下で行われた決定でした。
AIのGPU側はうまくいっていないと言えるかもしれませんが、NVIDIAやIntelのような資源を持っていない状態からスタートしたことを考えると、かなりのアンダードッグポジションからの出発でした。CPUでこれほどうまく実行できたことだけでも驚くべきことで、おそらくそれができた人はほとんどいないでしょう。
「今年の人物」に選ばれたことは知りませんでしたが、彼女はそれに値します。間違いなくハードウェアビジネスにおける最高のCEOの一人です。おそらく全体的に見ても最高のCEOの一人でしょう。なぜなら、ハードウェアビジネスは最も難しいビジネスだからです。SpaceXのような他の例を考えることはできますが、これは最も難しいビジネスです。
さらに言えば、ゲームコンソールのAPUや、Steam Deckやハンドヘルドでの低消費電力など、CPUの一つの分野で勝利を収めたことだけでも記念碑的なことです。そのような勝利の一つ一つが素晴らしいことです。CPUへの投資を完全に自分たちの側に引き寄せたという事実、現在サーバーファームはIntelを選んでいないという事実は信じられないことです。
それは、これらのベンダーにとって最も重要な市場セグメントです。なぜなら、データセンターは最も利益率が高いからです。今年のデータセンターの構築は大部分がAMDだと想像します。より良いチップを持っており、Intelのチップは来年のデータセンターでは競争力がないと予想されています。本当に驚くべきことで、どうやってそれを成し遂げたのか分かりませんが、彼女がやっていることは続けるべきです。
嘘をつきました。実は質問が2つあります。一つは短く済むはずで、もう一つは短くならないと分かっていますが、それでも良いと思います。もし時間がなければ、それも全く問題ありません。
いいえ、全く問題ありません。
素晴らしい。最初の質問ですが、これは以前見たことがあります。共有した人を見つけられませんが、とても良いと思いました。現在のプロセッサのボトルネックは何で、それは今後変化すると思いますか？今日のチップを遅くしている要因は何でしょうか？
プログラマーです。完全に。プログラマーがボトルネックです。これはチップの設計に本当によく表れています。
現在のプログラミングモデルの問題、特にCPU側の問題は、私たちが一連の線形的な出来事を書き下ろすということです。ほとんどのプログラマーはそれに多くの時間を費やしています。「これとこれを足して、これを見て、ハッシュテーブルでこれを探して、このif文を実行して、これ、これ、これ」という具合に、順番に実行しなければならない巨大な直列依存チェーンを作っています。
私たちは直列依存チェーンを単純に実行する速度の限界にずっと前に到達しました。CPUアーキテクチャの図で示したすべてのこと、なぜ並列で多くの命令をデコードするのか、なぜ命令ストリームからこれらのことを実行し投機的に実行するのか、なぜ分岐予測が必要なのか、それらすべては、順番に実行しなければならないと指定されたものから並列性を見つけ出そうとしているからです。
順番を変えられるものを探し、事前に開始できるものを探して、そういったことを全て試みているのです。代わりに、GPUが使用するようなプログラミングモデル、常に何百万もの処理を考えるプログラミングモデル、何百万のピクセルを同時にシェーディングし、何百万の三角形を同時に処理するようなモデルを持っていれば、アーキテクチャはより効率的になれます。
GPUがCPUと何が違うのか、自問してみてください。NVIDIAはIntelやAMDよりもモノ作りが上手いのでしょうか？CPUを作る時よりも4090を作る時の方がそれだけ賢いのでしょうか？いいえ、並列実行に集中できるからです。与えられるものが本質的に並列だからです。
AMD自身を見てみましょう。なぜ彼らのGPUはCPU単体でできる以上のレンダリングができるのでしょうか？同じ会社なのに。再び、それは完全に並列な問題として提示されているからです。彼らは完全に並列に実行するようにハードウェアを設計できるのです。
ここでは多くのことを省略していて、メモリの問題や他の理由もありますので、単純すぎるように聞こえないようにしたいのですが、本質的にはそういうことです。
AIモデルのトレーニングのような十分に複雑なタスクでは、その方向に進まなければなりません。並列で実行しなければ、全く実行できません。決して終わりません。
そして、CPUを見て、なぜ今より速く実行できないのかというボトルネックを考えると、それはプログラミングです。根本的に異なる方法でプログラミングしていれば、簡単にもっと速く実行できたはずです。
通常、私たちが最も弱いリンクなのです。印象的と考えられる性能向上を示すCPUを見るとき、このCPUとあのCPUの間で15%、あるいは20%の世代間の性能向上があったとしても、実際に見ているのは、ほとんどの場合、より多くの並列作業を見つけ出すことで補償しているか、キャッシュの量を増やすことで悪いアクセスパターンを修正しているか、物事の保存方法についての私たちの怠慢さを修正しているかです。
基本的に、私たちの下手な仕事を取り繕おうとしているのです。常にそうというわけではありません。時には「いや、私は本当に最適化された素晴らしいプログラムを書いて、それはただキャッシュが必要で、それを得て速くなった」ということもあります。しかし、多くの場合、私たちが最も弱いリンクであり、十分に並列なワークロードを与えていないのです。
プログラミングモデルを改善することが最も大きな改善点になるでしょう。それを除外すると、ボトルネックは何かと言えば、本当にハードウェアエンジニアに聞く必要があります。
多くの場合、このCPUにいくら使いたいかということです。常により多くのものを追加することができます。より多くのスケジューラー、より多くのデコードユニットを使用する、これはMシリーズが登場したときに見られたことです。彼らは全てを本当に強力にすることを決め、それはより良いパフォーマンスを発揮します。
ボトルネックは本当に、それらのものをより多く追加すること、より多くのデコーダーを追加すること、より多くの実行ユニットを追加すること、より大きな実行ウィンドウを追加することなどです。だからこそ、プロセス技術の改善、つまりダイの縮小などが重要なのです。より多くのものを搭載できれば、より多くの並列処理が可能になります。
では、今後はJavaScriptのV8エンジンをプロセッサに組み込む必要があるということですね。
いいえ、JavaScriptのプログラミングをやめる必要があるかもしれません。でも、それは起こらないでしょう。
では、それをアセンブリにコンパイルすれば、みんなが勝者になれるのでは？
できることは、先ほど言ったように、JavaScriptのプログラミングモデルが異なっていれば...基本的に、プログラマーがバッチで考えるように、常に何百、何千というものを一度に処理することを考えるように書くのです。一度に一つずつではなく。
そのようなよりバッチ指向のプログラミングモデルがあれば、JavaScriptであっても問題ありません。なぜなら、V8エンジンは「これは全てバッチ処理だ、これらの全てのことをSIMDユニットで幅広く、多くのスレッドで同時に実行できる」ということが分かるからです。
突然、物事がずっと簡単になります。シェーダーのメンタリティで書かれた未来のJavaScriptを想像することができ、それは何かになるかもしれません。
JavaScriptは、メインスレッドで全てが同期的に実行されるという事実を受け入れれば、組み込みの並行性としては良いものの一つだと言えます。非同期モデルによって、同期的な作業を処理し続けながら、バックグラウンドで実行されるタスクをキューに入れることができ、これは他の言語がデフォルトで並列処理に飛び込まなくても許可するよりも、単一のスレッドでより多くのことができるようになります。
数千のリクエストがあるアプリケーションで、それらのリクエストが全てデータベースリクエストでIO boundされている場合でも、レスポンスを生成する実際のプロセスがメインスレッドで完全に同期的に行われていても、それらの数千のリクエストを同時に処理できるという事実は本当に有益です。そして、将来的にはそのような作業がより多く分離されるモデルになる可能性があります。
JavaScriptのワーカーモデルは最悪です。本当に嫌いです。それを使って面白いものを作ろうと本当に頑張りました。最近、ビデオを作りました。最速のサーバーレンダリングJavaScriptフレームワークを作り、他の何よりも10倍速く、それは完全にワーカーを使用した並列処理のハックに基づいていますが、それは楽しくありません。
そうですね、先ほど言ったように、それは起こり得ます。JavaScriptを取り上げて「SIMDで幅広く実行できるようにする方法は何か」と考えることはできます。すでにそうしているので、利用可能な場合、JITはそれらを活用します。ただし、プログラミングモデルがプログラマーにそのような結果になるようなことをするよう促していないだけです。
現在、クレイジーな文字列操作以外にスレッド間でメモリを共有する方法がありません。それは修正されつつあります。共有構造体の提案があり、本当にクールです。それについてもビデオを作りました。とても興奮しています。なぜなら、ついにオブジェクトを持ち、unsafe blockを持ち、ここでアクセスしていると言って、独自のミューテックスを構築できるようになるからです。
これにより多くの楽しいことができるようになりますが、そこに到達するまでにはまだ時間がかかります。そして、GPUで起こっていることからはまだ世代分遅れています。
誰かが先ほど言っていました。正確な引用を見つけたいと思います。チャットのLucian Galaxyからです：「GPUで400万のデータポイントを100ミリ秒で処理でき、GPUの使用率が1%も超えないことに驚きました。そして、その100ミリ秒の90%がGPUとの不適切な通信だったことが分かりました。」
そうですね。コンピュータは多くの人が経験するよりもずっと速いです。なぜなら、そこには大量の無駄があるからです。
だからこそ、マイクロアーキテクチャのようなものについてもっと知ってもらおうとしているのです。これらのものがどれだけ速く、どれだけのパワーを持っているかを理解し始めると、常にどれだけ使用率が低いように見えるかが分かるからです。
はい、ストリーム後にブラウザでJavaScriptで構築しているゲームの作業に戻るのは、本当に痛みを伴うでしょう。
そうですね、先ほど言ったように、JavaScriptのV8は適切に駆動すれば、それなりのコード生成を行うと思います。そのあたりを調べてみるのも良いかもしれません。JavaScriptのJITが生成するコードを見る最も簡単な方法は何でしょうか？GDBにはそれがありませんが。
いいえ、そしてその上、コードを即座にJITコンパイルすることはありません。そのコードが十分にヒットしてJITする価値があると判断するまで待ちます。
そうですね、それがJITのやり方です。また、通常は遅延最適化も持っています。「これは重要なパスなのか？より重く最適化しよう」といった具合です。
実際の最後の質問です。今起こっていることから思いついたのですが、量子コンピューティングについて、最近の状況をどう感じていますか？
正直なところ、量子については完全に無知です。答えられません。賢い人々がこれに取り組んでいて、プログラミングを始める必要があるときに教えてくれると考えているだけです。
でも、Googleの最近の発表は見ましたか？
何も知りません。何と言っていましたか？
チップが動作しているそうです。Deep freezeとか呼ばれていると思います。とてもうまくいっているようです。大きな進展は、不良キュービットのエラー修正を探求していて、大きなダイの方が不良ノードの修正と識別が実際に容易だということを学び、そのためにプロセスを拡大して、はるかに多くのノードを持つようになったということです。
結果として、はるかに多くのキュービット数を持ち、エラーが大幅に少なくなり、RSA鍵を非常に素早く解読できたそうです。
鍵の大きさはどれくらいでしたか？
覚えていません。
ある時点で完全に崩壊しない限り、奇妙な日になるでしょう。楽円曲線を解読できないという前提の上に多くのものが構築されています。暗号通貨もこれに基づいており、ウェブ通信もこれに基づいています。
彼らがそうして、誰もが量子セキュアなものに切り替えなければならないとしたら、何が起こるのか分かりません。私の専門分野ではありませんが、少し怖いことは確かです。誰がその作業を全て行うのか、どのように行うのか分かりません。
時々、DJ Bernsteinの記事を読んで、現在行っている暗号化の量子セキュアな代替案について語っているのを見ますが、現在行っているものと比べて非常にコストがかかるように聞こえます。分かりません。
チャットの誰かGoogleが完了した具体的な課題を知っていますか？それについて聞いたことはありますが、クリックしている記事は全て有料で、とても腹が立ちます。
ウェブ開発者として、私はこれらの情報がどのように抽象化されているかが嫌いです。どこにあるのでしょうか？100年以上かかるはずの課題を1時間で完了したという特定の課題を思い出そうとしていますが、その課題の名前が思い出せません。
アイスキューブチャレンジのようです。誰かが見つけました。はい、URLはQuantum ai.googleです。もちろん、彼らは一度だけGoogleのTLDを使用しています。
最先端の... 実際のチャレンジを見せてください、Google。これが量子の話の全ての問題です。実際の情報を全く与えず、同じことを何度も繰り返すだけです。
そうですね、私は本当によく知らないので、理論的に量子コンピュータが何を可能にするかということは知っています。そして、「それは望まない」と思うだけです。なぜなら、今のところ、現在の暗号を全て破壊する以外に、これで何をしたいのか分からないからです。
他に気にするような実用的な用途があるのかもしれませんが。N二乗の問題を解くことを気にするでしょうね。
暗号化が破られることには興奮していません。これはすでに可能に見えます。国家主体が暗号化を破ることができるということは分かります。これがコンピュートにとってずっと良くて、ソフトウェアの書き方を変えるということではありません。
探していた数字を見つけました。ランダム回路サンプリングベンチマークは、最速のスーパーコンピュータでも10セプティリオン年かかるところを、彼らの新しい量子チップで5分で行ったそうです。
まあ、とにかくクールですよね。量子を使って実際に計算する方法を見つけ出したのはクールです。長い間、誰も実際に実用的に機能するかどうか分かりませんでしたから。
かなり魔法のようなものですが、繰り返しになりますが、「クールだ」以外の反応はありません。暗号化に何が起こるのか心配です。基本的に、post-quantum（耐量子）な方式に切り替える必要があり、それは全て遥かに遅くなるでしょう。
ビットコインの人々が何を計画しているのか分かりません。暗号通貨への影響について考えもしませんでした。それらのうちどれだけが量子セキュアになる計画を持っているのか分かりません。いくつかは他よりも問題が大きいと想像しますが、実際に調べたことがないので分かりません。
うまくいくかもしれませんし、「ああ、ビットコインは終わりだ」となるかもしれません。分かりません。イーサリアムにはそれに対する計画があると知っています。誰かが指摘しました。誰もビットコインが何をしているのか知りません。誰も決してビットコインが何をしているのか知りません。
そうですね、最も人気があるのに。誰もビットコインが何をするか知らないのに最も人気があるなんて、すごいですね。
以上が私の質問です。ついに、あなたがそれほど詳しくない何かを見つけられて嬉しいです。私も全く詳しくないので、それは...はい、これで全てです。
宣伝したいこと、人々があなたの話をもっと聞いたり、支援したりできる最適な場所は何ですか？
実際には、computerenhance.comに行けば、私の全ての学習教材があります。無料のコンテンツもあり、このような内容が好きな場合は有料コンテンツもあります。とても人気があり、それは素晴らしいことです。
このストリームで話した全てのことが、そこにあります。コードから始めて、マイクロアーキテクチャがどのように実行されるかを見て、それがどのように機能するかを理解し、そこから一般化して、日々のコーディングの選択について考える、低レベルで何が起こっているのかを理解したら、「ああ、もっと効率的にできる」と考えられるようになります。
興味があれば確認してみてください。メールアドレスを登録してください。あなたを歓迎します。
Substackで38,000人の購読者がいるのは本当に驚異的です。おめでとうございます。それは大きな成果です。そして、そのドメインも素晴らしいです。computer enhance。これは、私がブレードランナーのあのシーンに合成されているところです。どんどんズームインしていくシーンですよね。
はい、そうです。これは世界で最も簡単な推薦です。私は知っています。この動画をここまで見てきた視聴者の多くは、もし私のチャンネルに載せられれば、おそらくJavaScriptの世界で多くの時間を過ごしていると思います。
これは少し抜け出す方法です。JS に深く入り込んで他のことが見えなくなってしまうことがどれほど簡単かを知っています。私にもそういうことがありました。これらは私が消費するもの、私が見るものです。antech に行き、computer enhance に行き、これらの全ての種類のソースに行きます。なぜなら、これらのことを知りたいし、コンピュータの世界で起こっている多様なことを知りたいからです。
これらの抽象化レベルのどれかで生きることもできますが、他のレベルも理解すべきです。なぜなら、結局のところ、あなたがしている作業の一部は、これらの他のものと並行して動いているからです。Caseyがしていることは、私のダメなJavaScriptコードが動作するシステムを構築することです。
JavaScriptの世界で私たちがしていることは、これらの低いレベルで実行され、これらは時間とともにますます重要になっていくでしょう。コンピュータの仕組みについて情報を得る場所の多様性を持つことが重要です。なぜなら、全てのレベルで異なり、Caseyは私がここで十分に話していない低レベルの情報の最高のソースの一つだからです。
その推薦に本当に感謝します。実際に、私が持っている教材の最初の方で、Pythonを見て、「Pythonプログラムがa + bのような足し算をしたい場合に必要な全ての命令を見てみましょう」というようなことをしています。
多くの人がそのようなことを本当に楽しんでいます。なぜなら、「これを直接マイクロまで結びつけることができます」というようなことを見せるからです。これらの高水準言語が単純なことを実行するのに実際にどれだけの作業を必要とするかを見ると、それは本当に驚くべきことです。
そのような理解を持つことは、少なくとも私はそう思いますが、どの言語を使うか、物事をどのように行うかについての高レベルの決定を行う上で大いに役立ちます。
はい、その通りです。computer enhanceにもっと注目を払うつもりです。パート4は近々公開されると言いましたよね？
はい、パート4は既に始まっています。最初のビデオは先週でした。このパート4は基本的に計算についてです。前のパート3では、メモリを見ていました。基本的に、見ていたzen4の図の理解の導入として、メモリに関してそれがどのように機能するかを考え、理解することを示していました。
パート3では、コアへの、そしてコアからのメモリの移動、読み書き、そしてオペレーティングシステムで起こることも扱いました。ページマッピングやアドレス変換など、そのシステム全体がどのように機能するかを学ぶことがパート3でした。
パート4は計算についてです。下部にあるそれらの実行ユニットをどのように駆動するのか、それらは何ができるのか、それらを効果的に使用できるかどうかを何が決定するのか、そういったことが全てパート4の内容です。
はい、具体的な例を使用し、多くのマイクロベンチマークを行います。物事を実行し、実際に測定する方法を示します。「ここに小さなものを入れると、突然半分の速さになります。なぜでしょうか？CPU内部でこれが起こっているからです」というように。
とても実践的に教えようとしています。常に非常に具体的です。
それが大好きです。低レベルの分野にはこういったものが十分にありません。全てが非常に抽象的で、情報さえ与えず、与えたとしても、それがどのように関連しているかを示していません。それは私が永遠に抱えてきた課題です。
4chanで読むものと、私がJavaScriptの世界で書くものの間の橋、その溝は広すぎます。あなたはその間を埋めてくれました。それをしてくれて本当に感謝しています。
そうですね、これほど注目を集めることが嬉しいです。本当に素晴らしかったです。そして、まだ言っていなかったと思いますが、ストリームに呼んでくれてありがとうございます。本当に楽しかったです。楽しみにしていたし、予想通り楽しかったです。素晴らしいホストとして迎えてくれて本当にありがとうございます。とても感謝しています。
たくさんのことをありがとうございます。そして、pingが4時間連続で生き残ったことを嬉しく思います。通常、どこかで何らかの同期の問題が発生しますが、全てのことを考慮すると、これは驚くほどうまくいきました。
それを作ったんですか？pingを？それは素晴らしいですね。以前使ったことがあります。Primeが彼のチャンネルに出たとき、彼が私にリンクを送ってくれました。あなたが作ったとは知りませんでした。それは素晴らしいですね。ありがとうございます。
これは、私がコンテンツクリエイターになる前に作りました。Twitchで5年間働き、コロナ禍の間にスタートアップに参加し、気が狂いそうになって辞め、他の仕事を探し始めました。そして、2人の他の創業者にpingを本当のビジネスにするよう強要されました。
友人たちのライブコラボを手伝うために副業として作っていましたが、ゲストをOBSに招くのがとても大変だったからです。楽しくありません。pingは、コンテンツクリエイター向けのライブコラボを行うためのZoomのようなものです。他のツールは全て、ポッドキャストを作ることや、使いにくいデスクトップアプリを使用することに重点を置きすぎていました。ビデオ通話のように簡単にOBSに接続できるものを作りたい人は誰もいませんでした。それが私たちがpingを作った理由です。
とてもうまくいき、最初は、どれだけ早く広がったかに本当に驚きました。しかし、比較的早くピークに達しました。高品質なライブコラボに興味を持つ人の数は比較的少ないのです。それ以来、主に開発者向けツールに焦点を移してきました。
とは言え、pingは依然としてトップ100ストリーマーのほとんどがライブコラボに使用しています。Austin Showはカップルマンスごとにゲームショーを行い、20万人のライブ視聴者と、その後数百万の視聴者を集めていますが、彼らは2年以上pingを使用しています。予算の高いライブコラボ制作では、現在では相当な確率でpingが使用されています。
それは素晴らしいですね。そして、ビジネス上の課題の一つは、ストリーマー向けのものであり、その数が十分でないということですよね。残念ながら、それは小さな市場です。その意味で、自立させるのは難しいと想像します。でも、とても良いシステムのように見えます。
非常にうまく機能します。私たちは望むもの全てと、それ以上のものを作りました。クリエイターが必要とするものをより良く理解するために、もっとストリーミングとコラボを始めました。偶然にも、ビジネスを始めた後に開発者向けのYouTubeで本当に人気が出て、それが今日私たちがここにいる理由です。
それは素晴らしいですね。pingが作られた市場をより良く理解しようとする試みに基づく偶然でした。
その通りです。私は何よりもまずウェブ開発のCEOです。このYouTubeの件は、まだパートタイムの仕事のふりをしています。最近ではそのふりも難しくなってきましたが。偶然のYouTuberですね。そこに落ちていったんですね。
それも素晴らしいですね。製品を使っていたと聞いて嬉しいです。うまく機能していて、ここでもこれほどうまくいったことに興奮しています。そして繰り返しになりますが、全てのことに感謝します。これは本当に素晴らしかったです。
私にとっても喜びでした。また話したいときは、いつでも教えてください。
はい、そして、先ほど提案したLTTとの紹介について金曜日までに連絡がなければ、DMください。それを実現させます。彼らはあなたとコラボする本当に良い機会があると思います。
もちろん、そしてそれにもpingを使うかもしれませんね。
ありえますね。彼らはしばらくpingを使っていましたが、OBSから離れたかったのでvmixに移行しました。しかし、うまくいけば近いうちにまたpingに戻ってくれることを期待しています。
よし、素晴らしいです。再度全てに感謝します。Caseyを見つけたい人は、computerenhance.comが最適な場所です。YouTube動画もチェックしてください。Twitchアカウントは、特によく配信していますか？
ほとんどしていません。Twitterでも見つけることができます。単にCmurorです。
再度ありがとうございます。本当に感謝しています。
ありがとうございます。良い一日を。
あなたも良い一日を。さようなら。

いいなと思ったら応援しよう！