00:17 イントロダクション
03:35 桁数のオーダー
06:55 サプライチェーン最適化のステージ
12:17 ハードウェアのSカーブ
15:52 これまでの話
17:34 補助科学
20:25 モダンコンピューター
20:57 レイテンシー 1/2
27:15 レイテンシー 2/2
30:37 計算、クロック速度
36:36 計算、パイプライニング、1/3
39:11 計算、パイプライニング、2/3
40:27 計算、パイプライニング、3/3
46:36 計算、スーパースカラー 1/2
49:55 計算、スーパースカラー 2/2
56:45 メモリ 1/3
01:00:42 メモリ 2/3
01:06:43 メモリ 3/3
01:11:13 データストレージ 1/2
01:14:06 データストレージ 2/2
01:18:36 帯域幅
01:23:20 結論
01:27:33 今後の講義と視聴者の質問
説明
モダンなサプライチェーンは、モーター駆動のコンベアベルトが電気を必要とするように、コンピューティングリソースを必要とします。しかし、遅いサプライチェーンシステムは依然として普及しており、一方でコンピューターの処理能力は1990年以来、10,000倍以上に増加しています。ITやデータサイエンスの分野でも、モダンなコンピューティングリソースの基本的な特性に対する理解の欠如は、この状況を説明する上で重要な要素です。数値計算の基礎となるソフトウェア設計は、基盤となるコンピューティング基板と対立すべきではありません。
フルトランスクリプト
このサプライチェーンの講義シリーズへようこそ。私はジョアネス・ヴェルモレルです。今日は「サプライチェーンのためのモダンコンピューター」を紹介します。西洋のサプライチェーンは長い間デジタル化されており、時には30年前からです。コンピュータに基づく意思決定はどこにでもあり、関連する数値計算は、リオーダーポイント、最小最大在庫計画、安全在庫など、さまざまな名前で呼ばれていますが、人間の監視の度合いは異なります。
それにもかかわらず、現在、同等に大規模なサプライチェーンを運営している大企業を見ると、本質的にコンピュータによって駆動される数百万の意思決定が行われていることがわかります。したがって、サプライチェーンのパフォーマンスの改善に関しては、サプライチェーンを駆動する数値計算の改善にすぐに結びつきます。ここで、どのような種類の優れた数値計算を考え始めても、より良いモデルとより正確な予測を望む場合、それらの優れた計算は、より多くの計算リソースを必要とすることが多いです。
計算リソースは、サプライチェーンにとってお金がかかるため、常に進化の次の段階があります。次のモデルや次の予測システムには、前のものよりも10倍以上の計算リソースが必要です。はい、それによって追加のサプライチェーンのパフォーマンスがもたらされるかもしれませんが、それには増加した計算コストが伴います。過去数十年間、コンピューティングハードウェアは非常に進歩してきましたが、今日私たちが見るように、この進歩はまだ進行中ですが、エンタープライズソフトウェアによって頻繁に妨害されています。その結果、ソフトウェアはよりモダンなハードウェアで速くなることはなく、むしろ非常に頻繁に遅くなることがあります。
この講義の目標は、聴衆の皆さんに機械的な共感を持たせることです。つまり、優れたサプライチェーンのパフォーマンスを提供するために意図された数値計算を実装するはずのエンタープライズソフトウェアが、既存のコンピューティングハードウェアと将来10年後のハードウェアをどのように受け入れているか、または妨害しているかを評価できるようにすることです。
モダンコンピュータの最も困惑する側面の1つは、関与する桁数の範囲です。サプライチェーンの観点から見ると、通常、5桁の範囲がありますが、それすらも限られています。5桁の範囲とは、1ユニットから100,000ユニットまで移動できることを意味します。以前の講義で私が話したことを思い出してください。小さな数の法則が働いています。大量のユニットがある場合、それらのユニットを個別に処理するのではなく、ボックスに詰め込んで、より少ない数のボックスになります。同様に、多くのボックスがある場合は、パレットに詰め込んで、より少ない数のパレットになります。規模の経済によって数量の予測が生じ、物理的な商品の流れに関わる場合、10%の非効率性はすでにかなり重要です。
コンピュータの領域では、非常に異なります。ここでは15桁の範囲を扱っていますが、これは絶対に巨大です。1ユニットから1百万兆ユニットまで移動するため、その数は非常に大きく、実際には視覚化するのが非常に難しいです。1バイトはたった8ビットであり、文字や数字を表すために使用できます。一方、ペタバイトは100万ギガバイトのオーダーです。ペタバイトは、Lokadが現在管理しているデータ量のオーダーとほぼ同じです。大規模なサプライチェーンを運営している大企業も、1ペタバイトのオーダーのデータセットを操作しています。
1 FLOP（1秒あたりの浮動小数点演算）から1ペタFLOP（100万ギガFLOPS）まで移動します。これらの桁数は非常に巨大であり、非常に欺瞞的です。その結果、サプライチェーンの領域では、10％が非効率とされる場合、コンピュータの領域では、10％の非効率さではなく、10倍、または数桁の非効率さが一般的です。したがって、コンピュータの領域でパフォーマンスに問題がある場合、ペナルティは10％ではなく、システムは本来の速度の10倍、または100倍、さらには1000倍も遅くなります。それが問題です。エンタープライズソフトウェアと基礎となるコンピューティングハードウェアの間には、機械的な共感が必要です。
優れたサプライチェーンのパフォーマンスを提供することが期待される数値レシピを考える際には、概念的に興味深い成熟度の段階があります。実際には状況によりますが、通常、Lokadで特定されたものです。これらの段階は次のように要約することができます。それを動作させる、それを正しくする、それを速くする、そしてそれを安くする。
“それを動作させる” は、プロトタイプの数値レシピが本当に意図した結果を提供しているかどうかを評価することです。たとえば、より高いサービスレベル、在庫の削減、資産のより良い利用など、サプライチェーンの観点から価値のある目標を達成しているかどうかを確認することが最初の成熟度段階での目標です。
次に、「それを正しくする」必要があります。サプライチェーンの観点からは、基本的にはユニークなプロトタイプを本格的な製品品質のものに変換することを意味します。これには、数値レシピにある程度の正確さをデザインに組み込むことが一般的です。サプライチェーンは広範で複雑であり、さらに重要なことに非常に乱雑です。数値レシピが非常に壊れやすい場合、数値メソッドが良くても、簡単に間違えることができ、最初にもたらすべき利益に比べて何倍もの問題を引き起こすことになります。これは勝利の提案ではありません。正しくすることは、スケールで展開できるものを確保することです。次に、この数値レシピを速くする必要があります。ここで言う速いとは、ウォールクロック時間の速さです。計算を開始すると、数分以内、最長でも1〜2時間で結果を得るべきですが、それ以上はかかりません。サプライチェーンは乱雑ですし、会社の歴史の中で、スエズ運河に取り残されたコンテナ船、パンデミック、浸水した倉庫などの中断が発生することがあります。そうなった場合、迅速に対応できる必要があります。ミリ秒単位で反応することを言っているわけではありませんが、数日かかる数値レシピは、大規模な運用摩擦を引き起こします。人間の時間枠内で操作できるものが必要ですので、速くする必要があります。
なお、現代のエンタープライズソフトウェアはクラウド上で実行され、クラウドコンピューティングプラットフォームでより多くの計算リソースを支払うことができます。したがって、ソフトウェア自体がクラウドが提供するすべての処理能力を活用するために適切に設計されている必要はありませんが、クラウドコンピューティングプロバイダから多くの処理能力を借りているため、ソフトウェアは実際には高速になることがありますが、非常に非効率です。
次のステージは、メソッドを安価にすることです。つまり、クラウドコンピューティングリソースをあまり使用しないことです。この最終ステージに進まない場合、メソッドを改善することはできません。動作するメソッドがあり、正しいものであり、高速であるが、多くのリソースを消費する場合、現在使用しているものよりもさらに多くの計算リソースを必要とする数値レシピの次のステージに移行しようとすると、行き詰まります。現在のものよりも効率の悪い数値レシピで実験を開始できるように、持っているメソッドを非常に効率的にする必要があります。
この最後のステージでは、現代のコンピュータで利用可能な基盤となるハードウェアを本当に活用する必要があります。最初の3つのステージではそれほど親和性を持たずに管理できますが、最後のステージが重要です。覚えておいてください、「安くする」ステージに到達しないと、反復することができず、行き詰まります。だから、それが最後のステージであっても、これは反復的なゲームであり、繰り返し反復するためにはすべてのステージを経ることが不可欠です。
ハードウェアは進歩しており、指数関数的な進歩のように見えますが、実際にはこの指数関数的な進歩は数千のSカーブで構成されています。Sカーブとは、新しい設計、プロセス、材料、またはアーキテクチャを導入し、最初は以前のものよりも本当に優れていない曲線のことです。その後、意図したイノベーションの効果が現れ、急速に増加し、イノベーションの利益をすべて消費した後に平坦化します。Sカーブの平坦化は、コンピュータハードウェアの進歩の特徴であり、数千のこれらの曲線で構成されています。一般人の視点からは、これは指数関数的な成長と見えます。しかし、専門家は個々のSカーブの平坦化を見ており、悲観的な見方につながることがあります。専門家でさえ、誰もが驚くような新しいSカーブの出現と進歩の指数関数的な成長の継続を常に見るわけではありません。
コンピューティングハードウェアはまだ進歩していますが、1980年代や1990年代に経験した進歩の速度には程遠いです。進歩のペースは現在はずっと遅く、かなり予測可能です。これは、コンピューティングハードウェアの製造に新しい工場を建設するために必要な巨額の投資によるものです。これらの投資はしばしば数億ドルになり、5年から10年先までの見通しを提供します。進歩は遅くなりましたが、次の10年間のコンピューティングハードウェアの進歩についてはかなり正確な見通しを持っています。
数値レシピを実装するエンタープライズソフトウェアにとっての教訓は、将来のハードウェアがすべてを改善することを受動的に期待することはできないということです。ハードウェアはまだ進歩していますが、この進歩を捉えるにはソフトウェア側からの努力が必要です。10年後に存在するハードウェアでより多くのことができるようになりますが、それはエンタープライズソフトウェアのコアにあるアーキテクチャが基盤となるコンピューティングハードウェアを活用している場合に限ります。そうでなければ、今日よりも悪い結果になる可能性があります。これは、思われるほど非合理ではない提案です。
この講義は、サプライチェーンの講義シリーズの第4章の最初の講義です。サプライチェーンの第3章についてはまだ終わっていませんが、次の講義では、サプライチェーンの補助科学をカバーしている現在の章と、サプライチェーンの第3章を交互に取り上げる予定です。
プロローグの最初の章では、サプライチェーンを研究対象と実践の両方としての私の考えを紹介しました。サプライチェーンは、敵対的な行動や競争的なゲームによって悩まされる、凡庸な問題の集合体であることがわかりました。そのため、この分野では単純な直接的な方法論はうまく機能しません。そのため、第2章では、サプライチェーンを研究し、時間とともに改善するための実践を確立するために必要な方法論について説明しました。
第3章「サプライチェーンのペルソナー」では、解決策ではなく問題自体に魅了されることをモットーに、サプライチェーンの問題の特性に焦点を当てました。本日開始する第4章は、サプライチェーンの補助科学についてです。
補助科学とは、他の学問の研究を支援する学問です。価値の判断はありません。ある学問が他の学問よりも優れているわけではありません。例えば、医学は生物学よりも優れているわけではありませんが、生物学は医学の補助科学です。補助科学の視点は、医学科学や歴史学など、多くの研究分野で確立されており、一般的です。
医学科学では、生物学、化学、物理学、社会学などが補助科学に含まれます。現代の医師は、物理学の基礎を理解していないと能力がないとは言えません。例えば、X線画像を解釈するためには、物理学の基礎を理解する必要があります。同様に、歴史学も長い一連の補助科学を持っています。
サプライチェーンに関しては、一般的なサプライチェーンの教材、コース、書籍、論文の中で、補助科学について触れずに取り扱っていることが私の最大の批判です。サプライチェーンを孤立した知識の一部として扱っています。しかし、私は現代のサプライチェーンの実践は、サプライチェーンの補助科学を十分に活用することでのみ実現できると考えています。その中でも、本日の講義の焦点であるのは、コンピューティングハードウェアです。
この講義は厳密にはサプライチェーンの講義ではなく、サプライチェーンの応用を考えたコンピューティングハードウェアの講義です。私は、100年前とは異なる現代的な方法でサプライチェーンを実践するためには、これが基本的な要素だと考えています。
現代のコンピュータを見てみましょう。この講義では、サプライチェーンに対して何ができるかを見直し、特に企業ソフトウェアのパフォーマンスに大きな影響を与える側面に焦点を当てます。レイテンシ、計算、メモリ、データストレージ、および帯域幅について見直します。
光の速度はおよそ1ナノ秒あたり30センチメートルで、比較的遅いです。現代のCPUは5ギガヘルツ（1秒間に50億回の演算）で動作すると考えると、光が0.2ナノ秒で移動できる往復距離はわずか3センチメートルしかありません。つまり、光の速度の制約により、3センチメートルを超える距離での相互作用は起こりません。これは物理法則によって課される厳しい制約であり、いつか克服できるかどうかは不明です。
レイテンシは非常に厳しい制約です。サプライチェーンの観点からは、少なくとも2つの分散コンピューティングハードウェアが関与しています。分散コンピューティングハードウェアとは、同じ物理的な空間を占有することができない多くのデバイスを含むコンピューティングハードウェアのことです。もちろん、それぞれのデバイスは自身の寸法を持っているため、別々に配置する必要があります。しかし、サプライチェーンの性質上、地理的に分散しているため、それに応じてコンピューティングハードウェアも地理的に分散しています。光の速度の観点からは、3メートルしか離れていないデバイスでも、ラウンドトリップには100クロックサイクルかかるため、非常に遅いです。3メートルは光の速度と現代のCPUのクロックレートの観点からはかなりの距離です。
もう1つの分散のタイプは、水平スケーリングです。私たちが利用できるようにするための現代の方法は、10倍または100万倍強力なコンピューティングデバイスを持つことではありません。それがエンジニアリングされている方法ではありません。より多くの処理能力を得るためには、追加のコンピューティングデバイス、より多くのプロセッサ、より多くのメモリチップ、より多くのハードドライブが必要です。ハードウェアを積み重ねることで、より多くの計算リソースを利用できるようになります。しかし、それらのデバイスはスペースを取るため、センチメートル幅のコンピュータに集約することはできません。
レイテンシに関しては、プロフェッショナルなインターネット（自宅のWi-Fiではなく、データセンターで得られるレイテンシ）のレイテンシを見ると、既に光の速度の30%以内にあります。たとえば、フランスのパリ近くのデータセンターとアメリカのニューヨークの間のレイテンシは、光の速度の30%以内です。これは人類にとって信じられないほどの成果です。情報がインターネット上を光の速度に近い速さで流れています。改善の余地はまだありますが、物理学によって課せられた厳しい制約にはすでに近づいています。
その結果、金融取引のわずかなレイテンシを削減するために、ロンドンと東京を北極海底にケーブルで接続する企業さえ存在します。基本的に、レイテンシと光の速度は非常に現実的な懸念事項であり、私たちが持っているインターネットは、物理学のブレークスルーがない限り、本質的に最高の状態です。ただし、次の10年にはそのようなものは見込まれていません。
レイテンシが非常に困難な問題であるため、エンタープライズソフトウェアには重要な影響があります。情報のフローにおけるラウンドトリップは致命的であり、エンタープライズソフトウェアのパフォーマンスは、ソフトウェア内のさまざまなサブシステム間のラウンドトリップの数に大きく依存します。ラウンドトリップの数は、耐圧縮性のあるレイテンシを特徴付けます。ラウンドトリップの最小化とレイテンシの改善は、サプライチェーンの予測最適化など、ほとんどのエンタープライズソフトウェアにとって最も重要な問題です。レイテンシの軽減は、より良いパフォーマンスの提供につながることが多いです。
レイテンシによって導入される複雑さに対処するための興味深いトリックは、正確なクロックが分散コンピューティングで手に入りにくいことです。正確なクロックの欠如により、システムのさまざまな部分を同期するために多数のラウンドトリップが必要となります。正確なクロックがないため、ベクトルクロックやマルチパートタイムスタンプなどのアルゴリズムの代替手段が生じます。これらの追加のラウンドトリップはパフォーマンスに影響を与えることがあります。
Googleが10年以上前に採用した賢明な設計は、チップスケール原子時計の使用でした。これらの原子時計の分解能は、電子時計やコンピュータに見られる石英ベースの時計よりもはるかに優れています。NISTは、さらに精密な日次ドリフトを持つ新しいチップスケール原子時計のセットアップを実証しました。Googleは、内部の原子時計を使用して、グローバルに分散したSQLデータベースであるGoogle Spannerのさまざまな部分を同期し、ラウンドトリップを節約し、グローバルスケールでのパフォーマンスを向上させました。これは非常に正確な時間測定を通じてレイテンシをごまかす方法です。
10年後を見据えると、Googleはおそらくこのような賢明なトリックを使う最後の企業ではないでしょうし、チップスケール原子時計は比較的手頃な価格で入手できます。チップスケール原子時計の価格は、1,500ドル程度です。
さて、コンピューティングについて見てみましょう。コンピュータで計算を行うことに関するものです。クロック速度は80年代と90年代に改善の魔法の要素でした。実際、コンピュータのクロック速度を全体的に倍増させることができれば、どの種類のソフトウェアが関与しているかに関係なく、コンピュータのパフォーマンスを効果的に倍増させることができます。すべてのソフトウェアはクロック速度に応じて線形的に高速化されます。クロック速度を高めることは非常に興味深いですし、今でも改善が続いていますが、時間の経過とともに改善は平坦化しています。約20年前、クロック速度は約2 GHzでしたが、現在は5 GHzです。
この平坦化した改善の主な理由は、電力の壁です。チップ上のクロック速度を上げると、エネルギー消費量がおおよそ2倍になり、そのエネルギーを放熱する必要があります。問題は熱放散です。エネルギーを放熱できない場合、デバイス自体に損傷を与えるほど熱が蓄積されます。現在、半導体産業は1秒あたりの操作数よりも1ワットあたりの操作数に移行しています。
このエネルギー消費量を2倍にする30%の増加のルールは、二律背反の剣です。CPUの時間当たりの処理能力の四分の一を犠牲にすることができれば、実際には電力消費量を半分にすることができます。これは特にスマートフォンでは非常に興味深いです。エネルギーの節約が重要であり、エネルギー自体がコストの主要な要素であるクラウドコンピューティングでも同様です。コスト効果の高いクラウドコンピューティングの処理能力を持つためには、超高速のCPUを持つことではなく、エネルギー投資に対して1 GHzといった遅いクロック速度のCPUが提供する1秒あたりの操作数を増やすことが重要です。
電力の壁は、現代のCPUアーキテクチャがそれを緩和するためにあらゆる種類の賢明なトリックを使用している問題です。たとえば、現代のCPUはクロック速度を調整できます。一時的にクロック速度をブーストして熱を放熱する前に減速することができます。また、ダークシリコンと呼ばれるものを活用することもできます。アイデアは、CPUがチップ上のホットエリアを交互に切り替えることで、クロックサイクルごとに常に同じエリアをアクティブにするよりもエネルギーを放熱しやすくすることです。これは現代の設計の非常に重要な要素です。企業ソフトウェアの観点からは、スケーラビリティを確保することが本当に重要です。多くのCPUでより多くの作業を行いたいのですが、個々のプロセッサは以前のものよりも弱くなります。すべてが全体的に向上するわけではなく、ワットあたりの操作数が増えるプロセッサを持つことが重要です。このトレンドは続きます。
おそらく10年後、困難を伴うかもしれませんが、7 GHzまたは8 GHzに到達するかもしれませんが、それに到達するかどうかはわかりません。2021年のクラウドコンピューティングプロバイダのクロック速度を見ると、通常は2 GHzに合わせられているので、20年前のクロック速度に戻っています。それが最も費用対効果の高い解決策です。
現在のCPUのパフォーマンスに到達するためには、いくつかの重要なイノベーションが必要でした。私はいくつかのイノベーションを紹介しますが、特にエンタープライズソフトウェアの設計に最も影響を与えるものです。この画面では、80年代初頭までのプロセッサの命令フローが表示されています。グラフの上から下に時間を表して、各命令はフェッチ、デコード、実行、書き込みバックの一連のステージを経ます。
フェッチステージでは、命令をフェッチし、レジスタを取得し、次の命令を取得し、命令カウンタを増やし、CPUを準備します。デコードステージでは、命令をデコードし、内部マイクロコードを生成します。実行ステージでは、レジスタから関連する入力を取得し、実際の計算を行います。書き込みバックステージでは、計算した結果をレジスタのいずれかに格納します。このシーケンシャルプロセッサでは、各ステージには1クロックサイクルが必要であり、1つの命令を実行するために4クロックサイクルがかかります。クロックサイクル自体の周波数を増やすことは非常に困難であることがわかりました。
1980年代初頭以降、パイプライニングとして知られる重要なトリックが導入されています。パイプライニングは、プロセッサの計算を非常に高速化することができます。アイデアは、各命令が一連のステージを経るため、ステージを重ね合わせ、CPU自体が複数の命令のパイプラインを持つようにすることです。この図では、常に4つの命令が同時に実行されるパイプラインの深さ4のCPUが表示されています。ただし、これらの命令は同じステージにありません。1つの命令はフェッチステージにあり、1つはデコードステージにあり、1つは実行ステージにあり、1つは書き込みバックステージにあります。この単純なトリックにより、オペレーションのパイプライニングによってプロセッサの効果的なパフォーマンスが4倍になります。すべての現代のCPUはパイプライニングを使用しています。
この改善の次の段階は、スーパーパイプライニングと呼ばれています。現代のCPUは、単純なパイプライニングをはるかに超えています。実際には、現代の実際のCPUには30段階のようなステージが関与しています。グラフでは、例として12段階のCPUが表示されていますが、実際には30段階のようなものです。このより深いパイプラインでは、12のオペレーションが同時に実行されるため、同じクロックサイクルを使用しながら非常に良いパフォーマンスが得られます。
ただし、新たな問題が発生します。前の命令が終了する前に次の命令が開始されるため、依存関係がある場合に問題が発生します。次の命令の入力の計算がまだ完了していないため、待つ必要があります。私たちは利用可能なパイプライン全体を最大限に活用して処理能力を最大化したいのです。したがって、現代のCPUは1回に1つの命令だけでなく、500個の命令のようなものをフェッチします。彼らは将来の命令のリストを遠くまで見て、依存関係を軽減するためにそれらを再配置し、実行フローを交互に配置してパイプラインの完全な深さを活用します。
この操作を複雑にする要素はたくさんありますが、特に分岐があります。分岐はプログラミングにおける条件であり、たとえば「if」文を書くときなどです。条件の結果は真または偽になり、結果に応じてプログラムはあるロジックの一部を実行するか別のロジックを実行します。これは依存関係の管理を複雑にします。CPUは、次の分岐の方向を予測する必要があります。現代のCPUは分岐予測を使用しており、シンプルなヒューリスティックを使用して非常に高い予測精度を持っています。彼らは分岐の方向を99%以上の精度で予測することができます。これは、私たちのほとんどが実際のサプライチェーンのコンテキストで行うことができるよりも優れた精度です。この精度は、スーパーディープパイプラインを活用するために必要です。
分岐予測に使用されるヒューリスティックの一例を示すために、非常にシンプルなヒューリスティックは、分岐が前回と同じ方向に進むと言うことです。このシンプルなヒューリスティックは、90%の精度を提供します。このヒューリスティックにひねりを加えると、前回と同じ方向に分岐が進むが、起点を考慮する必要があるということです。つまり、同じ起点から来る同じ分岐である場合、約95%の精度が得られます。現代のCPUは、実際にはかなり複雑なパーセプトロン（機械学習の技術）を使用して分岐の方向を予測しています。
適切な条件下では、分岐をかなり正確に予測することができ、したがってモダンなプロセッサのフルパイプラインを活用することができます。ただし、ソフトウェアエンジニアリングの観点からは、特に分岐予測に関しては、プロセッサとうまく連携する必要があります。うまく連携しないと、分岐予測が間違ってしまい、それが起こると、CPUは分岐の方向を予測し、パイプラインを整理し、事前に計算を開始します。実際に分岐が遭遇され、計算が実際に行われると、CPUは分岐予測が間違っていたことに気付きます。誤った分岐予測は正しい結果をもたらすのではなく、パフォーマンスの低下をもたらします。CPUは、パイプライン全体をフラッシュするか、大部分をフラッシュして、他の計算が行われるのを待ってから計算を再開するしかありません。パフォーマンスの低下は非常に大きくなり、エンタープライズソフトウェアのロジックがCPUの分岐予測ロジックとうまく連携しないことにより、パフォーマンスが1〜2桁失われることが非常に簡単に起こります。
パイプライン化を超えたもう一つの注目すべきトリックは、スーパースカラ命令です。CPUは通常、スカラまたはスカラのペアを一度に処理します。たとえば、32ビット浮動小数点精度の2つの数値です。スカラ演算を実行し、基本的には1つの数値を一度に処理します。ただし、過去10年間のモダンなCPUはほぼすべてスーパースカラ命令を備えており、実際に複数のベクトルの数値を処理し、ベクトル演算を直接実行することができます。これは、たとえば、8つの浮動小数点数のベクトルと2番目の8つの浮動小数点数のベクトルを取り、加算を実行し、この加算の結果を表す浮動小数点数のベクトルを取得することができるということです。これらすべては1つのサイクルで行われます。
たとえば、AVX2のような専用の命令セットを使用すると、8つの数値のパックで32ビットの精度を考慮した演算を行うことができます。AVX512では、16個の数値のパックで同様の演算を行うことができます。これらの命令を活用できる場合、1つの命令、1つのクロックサイクルで、1つずつ数値を処理するよりもはるかに多くの計算を行うことができるため、処理速度が桁違いに向上します。このプロセスはSIMD（Single Instruction, Multiple Data）として知られており、非常に強力です。過去10年間の進歩の大部分は、処理能力の向上において、このSIMD命令によって推進されており、モダンなプロセッサはますますベクトルベースでスーパースカラです。ただし、エンタープライズソフトウェアの観点からは、比較的トリッキーです。パイプライン化では、ソフトウェアがうまく連携する必要があり、おそらく分岐予測とうまく連携しているかもしれません。ただし、スーパースカラ命令に関しては、何も偶然ではありません。ソフトウェアは、この追加の処理能力を活用するために、ほとんどの場合、いくつかのことを明示的に行う必要があります。それは無料ではありません。このアプローチを受け入れる必要があり、通常、データ自体を組織化する必要があります。データ並列性があり、データがSIMD命令に適した方法で組織化されているようにする必要があります。それは難しいことではありませんが、偶然では起こりませんし、処理能力の大幅な向上をもたらします。
現代のCPUは多くのコアを持つことができ、1つのCPUコアは独自の命令フローを提供することができます。非常にモダンなCPUでは、通常、最大で64個のコアまで到達することができ、つまり、64個の独立した並行実行フローがあります。非常にモダンなプロセッサから得ることができる処理スループットの上限である1テラフロップにほぼ到達することができます。ただし、それ以上の処理能力を得るためには、GPU（グラフィカルプロセッシングユニット）を見ることができます。思っていることとは異なり、これらのデバイスはグラフィックスとは関係のないタスクに使用することができます。
NVIDIAのようなGPUは、スーパースカラープロセッサです。高性能なCPUのように最大64個のコアを持つのではなく、GPUは10,000個以上のコアを持つことができます。これらのコアは、通常のCPUコアよりもはるかにシンプルでパワフルでも高速でもありませんが、その数ははるかに多いです。これにより、8個または16個の数値パックだけでなく、数千個の数値を一度にクランチしてベクトル命令を実行することができます。GPUでは、1つのデバイスで30テラフロップ以上の範囲を達成することができます。市場で最高のCPUは1テラフロップを提供するかもしれませんが、最高のGPUは30テラフロップ以上を提供します。それは桁違いの差であり、非常に重要です。
さらにそれ以上に、線形代数などの特殊な計算（ところで、機械学習やディープラーニングなどのことは本質的には行列に関連する線形代数です）には、TPU（テンソルプロセッシングユニット）のようなプロセッサを使用することができます。GoogleはTensorFlowのためにそれらをテンソルと名付けることにしましたが、TPUはむしろ行列乗算プロセッシングユニットと呼ばれるべきです。行列乗算の興味深い点は、データ並列性だけでなく、操作が非常に繰り返されるため、非常に多くの繰り返しが含まれることです。TPUをシストリックアレイとして組織化することにより、グリッド上の計算ユニットを持つ2次元グリッドとして、1つのデバイスで1000テラフロップ以上の範囲を達成することができます。ただし、注意点があります。Googleは通常の32ビットではなく、16ビットの浮動小数点数を使用しています。サプライチェーンの観点からは、16ビットの精度は悪くありません。つまり、操作の精度は約0.1％であり、多くの機械学習や統計的な操作にとって、0.1％の精度は正しく行われ、バイアスが蓄積されない限り、かなり優れています。
計算ハードウェアに関して進歩の道筋を見ると、より専門化されたより堅牢なデバイスに進むことがわかります。この専門化により、処理能力を著しく向上させることができます。スーパースカラー命令から移行すると、桁違いの向上が得られます。グラフィックスカードに移行すると、1つまたは2つの桁違いの向上が得られます。純粋な線形代数に移行すると、本質的に2つの桁違いの向上が得られます。これは非常に重要です。
ちなみに、これらのハードウェア設計はすべて2次元です。モダンなチップと処理構造は非常にフラットです。モダンなCPUは20層以上を持ちませんし、これらの層は数マイクロンしか厚くありませんので、CPU、GPU、またはTPUは本質的にフラットな構造です。もしかしたら、あなたは「第3の次元はどうなるの？」と思うかもしれません。実際のところ、エネルギーの放出の問題である電力壁のために、私たちは第3の次元には進むことができません。なぜなら、デバイスに注入されるすべてのエネルギーをどのように排出するかわからないからです。
次の10年について予測できることは、これらのデバイスが本質的に2次元のままであるということです。エンタープライズソフトウェアの観点から、最も重要な教訓は、ソフトウェアの中核にデータ並列性をエンジニアリングする必要があるということです。そうしないと、生の計算能力に関して進歩が起こっているすべての進歩を捉えることができません。ただし、それは後から考えることではありません。それはアーキテクチャの非常に中核で行われる必要があります。システム内で処理する必要のあるすべてのデータを組織化するレベルで行われる必要があります。そうしないと、20年前のようなプロセッサにとどまることになります。
今、80年代初頭のメモリはプロセッサと同じくらい速かったため、1つのクロックサイクルはメモリとCPUの両方で1つのクロックサイクルでした。しかし、もはやそうではありません。80年代以来、メモリの速度とプロセッサのレジスタ内のデータにアクセスするための待ち時間の比率は増加し続けています。最初の比率は1でしたが、現在は通常1000を超える比率です。この問題はメモリウォールとして知られており、過去40年間で増加し続けています。現在でも増加し続けていますが、非常にゆっくりと増加しています。これは主にプロセッサのクロック速度が非常にゆっくりと増加しているためです。プロセッサのクロック速度があまり進歩していないため、メモリウォールの問題はさらに増加していません。しかし、現在の状況は非常に不均衡であり、メモリへのアクセスはプロセッサ内に便利に配置されているデータにアクセスするよりも3桁遅くなっています。
この視点は、現在のほとんどの大学でまだ教えられている古典的なアルゴリズムに完全に反します。古典的なアルゴリズムの視点では、メモリへのアクセスには一定の時間がかかると仮定しており、メモリの任意のビットにアクセスするのに同じ時間がかかります。しかし、現代のシステムではこれは全く当てはまりません。特定のメモリ領域にアクセスするのにかかる時間は、実際のデータがコンピュータシステム内のどこに物理的に存在するかに非常に依存します。
エンタープライズソフトウェアの観点からは、残念ながら、80年代と90年代に確立されたほとんどのソフトウェア設計はこの問題を完全に無視していました。最初の10年間は非常に小さな問題でしたが、過去20年間で本当に膨れ上がりました。その結果、現代のエンタープライズソフトウェアのパターンのほとんどは、すべてのメモリに一定の時間アクセスできるという前提に完全に反します。
ちなみに、Python（1989年に最初にリリース）やJava（1995年にリリース）などのプログラミング言語を考え始めると、それは現代のコンピュータでのメモリの動作方法とは非常に相反します。オブジェクトがある場合、特にPythonのような遅延バインディングがある場合、何かをするためにはポインタをたどってメモリ内でランダムにジャンプする必要があります。そのジャンプのうちの1つが不運な場所である場合、1000倍遅くなる可能性があります。それは非常に大きな問題です。
メモリウォールの範囲をよりよく把握するために、現代のコンピュータの典型的な待ち時間を人間の時間にスケーリングしてみましょう。プロセッサが1秒ごとに動作していると仮定すると、CPUの典型的な待ち時間は1秒になります。しかし、メモリのデータにアクセスする場合、最大で6分かかることがあります。したがって、1秒ごとに1つの操作を実行できる一方で、メモリのデータにアクセスする場合は6分待たなければなりません。そして、ディスク上のデータにアクセスする場合、最大で1か月、または1年かかることがあります。これは非常に長い時間ですし、この講義の最初に言及した性能の桁数についてのものです。15桁の桁数を扱うと、非常に欺瞞的です。情報を正しい場所に配置しないと、文字通り数か月待たなければならないという非常に大きなパフォーマンスの低下に気付かないかもしれません。これは絶対に巨大です。
ところで、エンタープライズソフトウェアエンジニアだけが現代のコンピューティングハードウェアの進化に苦しんでいるわけではありません。例えば、Intel Optaneシリーズのような超高速SSDカードで得られるレイテンシを見てみると、このデバイスのメモリにアクセスするためのレイテンシの半分は、実際にはカーネル自体、この場合はLinuxカーネルのオーバーヘッドによって引き起こされていることがわかります。レイテンシの半分はオペレーティングシステム自体によるものです。それはどういう意味でしょうか？それは、Linuxを開発している人々でさえ、現代のハードウェアに追いつくためにさらなる作業を行う必要があるということです。それにもかかわらず、これは皆にとって大きな課題です。
ただし、これは特にサプライチェーンの最適化を考えると、エンタープライズソフトウェアにとって本当に痛手です。処理するデータがたくさんあるため、最初からすでに非常に複雑な作業です。エンタープライズソフトウェアの観点からは、キャッシュとうまく連携する設計を採用する必要があります。なぜなら、キャッシュにはアクセスが速く、CPUに近いローカルコピーが含まれているからです。
仕組みは次のようになります。現代のソフトウェアでは、メインメモリの1バイトにアクセスするだけではありません。RAMの1バイトにアクセスする場合、ハードウェアは実際には4キロバイト、つまり4キロバイトの大きさのページ全体をコピーします。その根本的な仮定は、バイトを読み始めると、次に要求するバイトはその次のバイトになるということです。これが局所性の原則であり、この原則に従ってアクセスを強制すると、プロセッサとほぼ同じ速度で動作するようなメモリを持つことができます。
ただし、これにはメモリアクセスとデータの局所性の整合性が必要です。特に、Pythonなどの多くのプログラミング言語は、これらの種類のことをネイティブで提供していません。それどころか、局所性のあるデータを持つことは非常に困難です。これは非常に困難な課題であり、結局のところ、私たちが利用できるハードウェアと完全に対立するパターンに基づいて設計されたプログラミング言語がある戦いです。この問題は今後10年間で変わることはありません。むしろ、ますます悪化するだけです。
したがって、エンタープライズソフトウェアの観点からは、データの局所性を強制するだけでなく、最小化も求める必要があります。ビッグデータを小さくすることができれば、より高速になります。これは直感的ではありませんが、冗長性を排除することでデータのサイズを縮小できれば、プログラムがより高速になります。キャッシュに対してはより優しくなります。より低いレイテンシを持つ下位キャッシュレベルにより多くの関連データを収めることができます。このディスプレイに示されているように。
最後に、DRAMの具体的なケースについて話しましょう。DRAMは、デスクトップワークステーションやクラウド上のサーバーで使用するRAMを構築する物理的なコンポーネントです。DRAMはまた、DRAMチップから構築されるメインメモリとも呼ばれます。過去10年間、価格の面ではDRAMはほとんど変化していません。1ギガバイトあたりの価格は、10年後に5ドルから3ドルにわずかに減少しました。RAMの価格はまだ下がっていますが、あまり速くはありません。次の数年間は停滞しており、この市場でDRAMを大量生産する能力を持つ3つの主要なプレーヤーしかいないため、今後10年間に予期せぬことはほとんどないでしょう。
しかし、それが最悪の問題ではありません。ギガバイトあたりの消費電力もあります。消費電力を見てみると、現代のRAMは10年前よりもギガバイトあたりに少し多くの電力を消費していることがわかります。その理由は、現在のRAMがより速くなっているためであり、同じく電力壁の法則が適用されます。クロック周波数を上げると、消費電力が大幅に増加します。ところで、DRAMは基本的にアクティブなコンポーネントであるため、RAMはかなりの電力を消費します。電気漏れのためにRAMを定期的にリフレッシュする必要があります。したがって、RAMの電源を切ると、すべてのデータが失われます。セルを常にリフレッシュする必要があります。
したがって、エンタープライズソフトウェアにとっての結論は、DRAMがもはや進歩していないということです。処理能力など、非常に急速に進歩しているものはたくさんありますが、DRAMには当てはまりません。非常に停滞しています。電力消費も考慮に入れると、クラウドコンピューティングのコストのかなりの部分を占めるRAMはほとんど進歩していません。したがって、ベンダーが「オーバーメモリの設計を持っています」と言う場合、メインメモリを過度に重視する設計を採用することを覚えておいてください。
ベンダーがインメモリの設計を持っていると言う場合、ベンダーが伝えていることは、将来のDRAMの進化に完全に依存しているということです。既にDRAMのコストは減少しないことはわかっています。したがって、10年後には、サプライチェーンがデータを処理するために10倍のデータを持つ可能性があることを考慮に入れると、大企業が大規模なサプライチェーンを運営している場合、現在よりも10倍のデータを収集することは合理的ではありません。ただし、RAMのギガバイトあたりの価格は変わらないでしょう。したがって、計算をすると、メモリに収まりにくい増え続けるデータの大量に対処する必要があるため、クラウドコンピューティングのコストやITコストがほぼ桁違いに高くなる可能性があります。重要なポイントは、あらゆる種類のインメモリ設計を避けることです。これらの設計は非常に時代遅れであり、次に示すように、どのような代替手段があるかを見ていきます。
さて、永続的なデータストレージであるデータストレージについて見てみましょう。基本的に、広く普及しているデータストレージには2つのクラスがあります。1つ目はハードディスクドライブ（HDD）または回転ディスクです。2つ目はソリッドステートドライブ（SSD）です。興味深いことに、回転ディスクのレイテンシはひどく、この図を見れば簡単に理解できます。これらのディスクは文字通り回転し、ディスク上の任意のデータポイントにアクセスする場合、平均してディスクの半回転待つ必要があります。最高級のディスクは約10,000回転/分で回転していることを考慮すると、圧縮できない3ミリ秒のレイテンシが組み込まれています。ディスクが回転し、ディスク上の特定のポイントを読み取るまでの時間です。これは機械的なものであり、これ以上改善されません。
HDDはレイテンシの点でひどいですが、もう1つの問題もあります。それは電力消費です。おおよそ、HDDとSSDはどちらもデバイスあたり1時間あたり約3ワット消費します。それが現在のボールパークの状態です。ただし、ハードドライブが稼働している場合、ハードドライブから何も読み取っていなくても、ディスクが回転し続ける必要があるため、3ワット消費します。10,000回転/分に到達するまでには多くの時間がかかるため、ディスクを非常に頻繁に使用しなくても、ディスクを常に回転させる必要があります。
一方、ソリッドステートドライブに関しては、アクセス時に3ワット消費しますが、データにアクセスしていない場合、ほとんど電力を消費しません。残留電力消費はありますが、ミリワットのオーダーで非常に小さいです。これは非常に興味深いことです。なぜなら、たくさんのSSDを持っていても、使用していない場合は、消費する電力の料金を支払う必要がないからです。過去10年間、業界全体が徐々にHDDからSSDに移行してきました。
この曲線を見ると、HDDとSSDのギガバイト当たりの価格が過去数年間で下がってきていることがわかります。ただし、価格は現在停滞しています。データは少し古いですが、過去数年間であまり変動していませんでした。過去10年間を見ると、10年前にはSSDは1テラバイトあたり2,400ドルと非常に高価であり、一方、ハードドライブは1テラバイトあたり60ドルでした。しかし、現在では、ハードドライブの価格は3分の1になり、1テラバイトあたり20ドルになっています。SSDの価格は25分の1以上になり、SSDの価格の下降傾向は止まりません。SSDは現在、そしておそらく今後の10年間で最も進歩しているコンポーネントであり、非常に興味深いです。
ちなみに、モダンなコンピューティングデバイス（CPU、GPU、TPU）の設計は、最大でも20層の2次元です。しかし、SSDの場合、設計はますます3次元になっています。最新のSSDは176層程度のものがあります。順序的には200層に達しています。これらの層は非常に薄いため、将来的には数千層のデバイスや桁違いのストレージ能力が期待できるのは合理的なことです。もちろん、ダークシリコンと電力散逸のため、常にすべてのデータにアクセスできるわけではありません。
実は、多くのデータは非常に頻繁にアクセスされません。SSDは、ビットをオンにすることはできますが、オフにすることはできないという特定のハードウェア設計を伴います。基本的には、最初はすべてのビットがゼロになっていると想像してください。ゼロを1に変えることはできますが、この1をローカルでゼロに戻すことはできません。それを行うには、8メガバイトにもなるブロック全体をリセットする必要があります。つまり、書き込み時には、ビットをゼロから1に変えることができますが、1から0に変えることはできません。1から0にビットを変えるためには、ブロック全体をフラッシュして書き直す必要があり、これにより、書き込み増幅として知られるさまざまな問題が発生します。
過去10年間、SSDドライブには、これらの問題を緩和するためのフラッシュ変換層と呼ばれる内部層があります。これらのフラッシュ変換層は、時間の経過とともにますます良くなっています。ただし、さらなる改善の余地があり、エンタープライズソフトウェアの観点では、SSDを最大限に活用するために設計を最適化することが重要です。SSDは、データを保存する際にDRAMよりもはるかに優れた選択肢ですし、賢く活用すれば、ハードウェア業界の進歩によって、10年後には桁違いの利益を期待することができますが、DRAMの場合はそうではありません。
最後に、帯域幅について話しましょう。帯域幅は、技術の面ではおそらく最も解決された問題です。ただし、帯域幅を実現できたとしても、現在の時点で絶対に狂気じみた帯域幅を実現することができます。商業的には、通信業界は非常に複雑であり、多くの問題がありますので、エンドユーザーは光通信の進歩の恩恵を実際には受けていません。
光ファイバトランシーバを使用した光通信の進歩は、まったく狂気じみています。それはおそらく、CPUが80年代や90年代に進歩していたようなものです。例を挙げると、波長分割多重化（WDM）や空間分割多重化（SDM）を使用すると、光ファイバの単一ケーブルで1秒あたり数十テラバイトのデータ転送が可能です。これは絶対に巨大です。単一のケーブルでデータセンター全体を実質的に供給できるポイントに達しています。さらに驚くべきことは、通信業界が古いケーブルを基にしてこれらの驚異的な性能を提供できる新しいトランシーバを開発したことです。実際には、道路や物理的な場所に新しいファイバを展開する必要はありません。10年前に展開されたファイバをそのまま使用して、同じケーブル上で桁違いの帯域幅を実現できます。
興味深いことに、光通信には一般的な法則があります。光通信が電気通信を置き換えるのに興味深い距離がどのくらい縮まるかということです。数十年前、20年前には、光通信が電気通信を上回るためには約100メートル必要でした。したがって、100メートル未満の距離では銅を使用し、100メートル以上の距離ではファイバを使用しました。しかし、最新の世代では、3メートルという短い距離でも光学が勝つことができます。10年後を見ると、半メートルという短い距離でも光通信が勝つ状況を見ることに驚かないでしょう。つまり、いつかはコンピュータ自体が電気通路よりも性能が高いため、光学パスウェイを内部に持つことになるかもしれません。
エンタープライズソフトウェアの観点から見ると、これは非常に興味深いことです。なぜなら、将来を見据えると、帯域幅は大幅に低下するからです。これは、Netflixなどの企業が大量の帯域幅を消費しているため、大幅に補助されています。これは、レイテンシーをごまかすために、ユーザーに対して事前に大量のデータを取得し、ユーザーがより低いレイテンシーで近くに持ち込まれたデータと対話できるようにするなどの方法を取ることができます。必要のないデータを持ち込んでも、問題はレイテンシーであり、帯域幅ではありません。実際に必要なデータの1000倍のデータを持ち込んで、それをエンドユーザーやプログラムが処理できるようにし、ラウンドトリップを最小限に抑えることで、パフォーマンスの向上が得られます。これは、今日行われているアーキテクチャ上の意思決定に深い影響を与えるため、10年後のこのハードウェアクラスの進歩によってパフォーマンスを向上させることができるかどうかが条件となります。
結論として、レイテンシーはソフトウェアエンジニアリングの観点から見ると大きな戦いです。これは、私たちが持つパフォーマンスの種類を本当に制約しています。パフォーマンスは非常に重要です。それはITコストだけでなく、サプライチェーンで活動する人々の生産性にも影響を与えます。最終的には、サプライチェーン自体のパフォーマンスにも影響を与えます。なぜなら、このパフォーマンスがなければ、本当にスマートで高度な最適化や予測最適化イベントを提供する数値レシピのようなものを実装することさえできないからです。しかし、全体的に見て、より良いパフォーマンスのためのこの戦いは、少なくともエンタープライズソフトウェアの領域では勝利していません。新しいシステムは、古いシステムよりも遅くなることがあります。これは深刻な問題です。遅いソフトウェアのパフォーマンスは、それに陥る企業にとって驚くべきコストを生み出します。
例を挙げると、より優れたコンピューティングハードウェアが必ずしもより優れたパフォーマンスを提供するわけではないと考えるべきではありません。インターネット上の一部の人々は、入力レイテンシーまたは入力遅延を測定することにしました。これは、キーを押した後に対応する文字が画面に表示されるまでの時間です。1983年のApple IIでは、1MHzのプロセッサを搭載しており、かかる時間は30ミリ秒でした。2016年には、非常に素晴らしいノートブックであるLenovo X1に2.6GHzのプロセッサが搭載されており、レイテンシーは110ミリ秒でした。つまり、数千倍も優れたコンピューティングハードウェアを持っているにもかかわらず、ほぼ4倍も遅いレイテンシーになってしまいます。これは、メカニカルシンパシーがなく、持っているコンピューティングハードウェアに注意を払わない場合に起こる特徴的な現象です。コンピューティングハードウェアを敵対すると、パフォーマンスが低下します。
問題は非常に現実的です。私の提案は、企業のための任意のエンタープライズソフトウェアを見るときに、今日学んだメカニカルシンパシーの要素を忘れないでください。ソフトウェアを見て、それがコンピューティングハードウェアの深いトレンドを受け入れているか、それらを完全に無視しているか、よく考えてください。それらを無視すると、パフォーマンスは時間の経過とともに改善されないだけでなく、おそらく悪化するでしょう。現在のほとんどの改善は、クロック速度よりも特殊化によって達成されています。このハイウェイを逃すと、時間の経過とともにますます遅くなる道を選んでしまいます。これらの解決策は、元々のキーデザインの決定から生じるもので、元に戻すことはできません。それらに永遠に取り残され、年々悪化するだけです。これらの視点を見るときに、10年先を考えてください。
さて、質問を見てみましょう。かなり長い講義でしたが、難しいトピックです。
質問: 量子コンピューターとその複雑なサプライチェーン最適化問題への有用性について、あなたの意見は何ですか？
非常に興味深い質問です。私は18か月前にIBMの量子コンピューターのベータ版に登録しました。クラウド上でアクセスを開放したときです。専門家はすべてのSカーブが平坦化しているのを見ることができますが、どこからでも新しいカーブが現れるのは見えません。量子コンピューティングはその一つです。ただし、サプライチェーンに関しては、量子コンピューターは非常に困難な課題を提起します。まず、先ほど言ったように、エンタープライズソフトウェアの観点から見ると、現在の戦いはレイテンシーですが、量子コンピューターはそれに何も寄与しません。量子コンピューターは、超タイトな計算問題に対して潜在的に10桁のスピードアップを提供します。したがって、量子コンピューターはTPUの次の段階になります。TPUでは、超タイトな操作を非常に高速に実行できます。
これは非常に興味深いですが、正直なところ、現在、私の知る限りでは、企業ソフトウェア内でスーパースカラ命令を活用している企業は非常に少ないです。つまり、スーパースカラGPUで利用できる10倍から28倍のスピードアップが市場全体で無駄になっています。サプライチェーンの世界では、それを行っている人はほとんどいません。Lokadかもしれませんが、そうでないかもしれません。TPUに関しては、私はまったく知りません。Googleは広範に使用していますが、サプライチェーンに関連するものをTPUで使用したことがある人は誰も知りません。量子プロセッサはTPUの次の段階になるでしょう。
私は確かに量子コンピューターの進展に非常に注目していますが、これは私たちが直面するボトルネックではないと考えています。それは70年前に確立されたフォン・ノイマン設計を見直すことでスリリングですが、これは私たちやサプライチェーンが次の10年間に直面するボトルネックではありません。それを超えた先には、あなたの推測が私の推測と同じくらい正しいです。はい、それはすべてを変える可能性がありますし、しない可能性もあります。
質問: クラウドとSaaSの提供により、組織は固定コストを活用し、変動コストに変換することができます。このようなサービスを提供している企業は、固定コストと関連するリスクを削減するためにも取り組んでいますか？
それは状況によります。もし私がクラウドコンピューティングプラットフォームであり、処理能力を提供しているのであれば、あなたのエンタープライズソフトウェアをできるだけ効率的にすることが私の利益になるでしょうか？実際にはそうではありません。私は仮想マシンやギガバイトの帯域幅、ストレージを販売しているので、実際には逆です。私の利益は、できるだけ非効率なソフトウェアを持っていることであり、それによって膨大なリソースを消費し、都度支払いをしてもらうことです。
Microsoft、Amazon、Googleなどの大手テック企業は、自社のコンピューティングリソースの最適化に非常に積極的です。しかし、クライアントに仮想マシンのレンタル料金を請求する際には、クライアントが使用しているエンタープライズソフトウェアが非常に非効率であるために、本来のサイズよりも10倍大きな仮想マシンをレンタルしている場合でも、彼らにとっては問題ありません。それは彼らにとっては良いビジネスです。システムインテグレーターとクラウドコンピューティングプラットフォームがパートナーとして協力する傾向にあることを考えると、これらの人々があなたの最善の利益を考えているわけではないことがわかります。さて、SaaSの場合は少し違います。実際に、Lokadのような場合、ユーザーごとにSaaSプロバイダーに支払いをする場合、それは会社の利益になります。私たちは消費するコンピューティングリソースに基づいて料金を請求するのではなく、通常は定額の月額料金でクライアントに請求しています。したがって、SaaSプロバイダーは自社のコンピューティングリソースの消費に非常に積極的です。
ただし、注意が必要です。SaaS企業の場合、クライアントにとってはより良いものになるかもしれないが、自社のハードウェアにとってはコストがかかるようなことをすることにはかなりの抵抗があるかもしれません。すべてがうまくいくわけではありません。サプライチェーンスペースで活動しているすべてのSaaSプロバイダーに影響を与える利益相反が存在します。たとえば、彼らはすべてのシステムを再設計してレイテンシを改善し、より高速なウェブページを提供することに投資することができますが、それにはリソースが必要であり、それを行った場合にクライアントから追加の支払いを受けることは自然にはありません。
この問題はエンタープライズソフトウェアに関してはさらに深刻化する傾向があります。なぜなら、ソフトウェアを購入する人と使用する人が通常異なるからです。そのため、エンタープライズシステムの大部分は非常に遅いのです。ソフトウェアを購入する人は、1年中毎日超遅いシステムに対処しなければならない貧弱な需要プランナーや在庫管理者ほど苦しむことはありません。したがって、エンタープライズソフトウェアの領域には特有の別の側面があります。状況を分析し、関与するすべてのインセンティブを考慮する必要があります。エンタープライズソフトウェアを扱う場合、通常は多くの利益相反が存在します。
質問: ハードウェアの進歩を考慮して、Lokadはどれくらいの頻度でアプローチを見直してきましたか？可能であれば、実際の問題解決の文脈にこの内容を置くための例を挙げることはできますか？
Lokadは、おそらく6回以上も技術スタックを大幅に再設計しました。ただし、Lokadは2008年に設立され、全体のアーキテクチャを何度も大幅に書き換えました。ソフトウェアはそれほど進歩していたわけではありませんが、私たちが再設計を行った主な要因は、ハードウェアの進歩ではなく、ハードウェアに関する理解を深めたことでした。私が今日紹介したすべてのことは、すでに10年前から注意を払っていた人々には基本的に知られていました。ですので、ハードウェアは進化していますが、進化のスピードは非常に遅く、トレンドのほとんどは10年先まで予測可能です。これは長期的なゲームです。
Lokadは大規模な書き換えを経験しましたが、それは私たちが徐々に無能ではなくなっていったことの反映でした。私たちは能力を向上させ、ハードウェアを受け入れる方法についてより良い理解を持つようになりました。ハードウェアがタスクを変えていたわけではありません。常にそうではありませんでした。私たちにとって本当にゲームチェンジングだった要素もありました。最も注目すべき要素はSSDです。私たちはHDDからSSDに移行し、パフォーマンスに完全なゲームチェンジをもたらし、アーキテクチャに大きな影響を与えました。具体的な例として、Lokadが提供するドメイン固有のプログラミング言語であるEnvisionの全体的な設計は、ハードウェアレベルで得た洞察に基づいています。これは単なる1つの成果ではありません。思いつくことをすべてより速く行うことに関してです。
10億行と100列のテーブルを処理し、同じ計算リソースで100倍速く行いたいですか？はい、できます。非常に大きなテーブル間の結合を最小限の計算リソースで行うことはできますか？はい、できます。エンドユーザーに表示される100個のテーブルを持つ非常に複雑なダッシュボードを500ミリ秒未満で作成できますか？はい、それを達成しました。これらはありふれた成果ですが、これらをすべて達成したことで、私たちは比較的洗練された予測的な最適化レシピを本番環境に導入できるのです。私たちは、そこに至るすべてのステップが非常に高い生産性で行われることを確認する必要があります。
数値的なレシピによるサプライチェーンに関して非常に洗練されたことを行いたい場合、最大の課題は「それを動作させる」段階ではありません。大学生を雇って、数週間でサプライチェーンのパフォーマンスを向上させる一連のプロトタイプを作成することはできます。Pythonとその日のランダムなオープンソースの機械学習ライブラリを使用して、学生たちは頭が良く、意欲的であれば、数週間で動作するプロトタイプを作成することができます。しかし、それを本番環境でスケールさせることはできません。それが問題です。それは「正しくする」、「速くする」、「安くする」という成熟度の段階をどのように乗り越えるかに関わります。そこで、ハードウェアの親和性が本当に輝き、反復する能力が問われます。
1つの成果ではありません。ただし、Lokadが確率的予測を行っていると言っても、それほど多くの処理能力は必要ありません。本当に処理能力が必要なのは、非常に広範な確率分布を活用し、すべての可能な未来を見つめ、すべての可能な意思決定と組み合わせることです。その方法で、財務最適化を行い、非常に高コストになります。最適化されたものがない場合、行き詰まります。Lokadが本番環境で確率的予測を使用できるという事実は、すべてのクライアントのパイプラインにおいて、ハードウェアレベルでの最適化が行われていることの証です。現在、約100社にサービスを提供しています。
質問: エンタープライズソフトウェア（ERP、WMS）には、レイテンシを回避するために社内サーバーを使用する方がクラウドサービスを使用するよりも良いですか？
現在では、それは重要ではありません。経験するレイテンシのほとんどはシステム内部にあります。これは、ユーザーとERPの間のレイテンシの問題ではありません。はい、非常に遅延がある場合、約50ミリ秒の遅延が追加されるかもしれません。もちろん、ERPをメルボルンに置いて、パリで運用することは避けたいです。運用地域にデータセンターを近づけたいです。ただし、現代のクラウドコンピューティングプラットフォームには数十のデータセンターがあり、社内ホスティングとクラウドサービスの間のレイテンシにはほとんど差がありません。
通常、社内ホスティングとは、ERPを工場や倉庫の真ん中の床に置くことを意味しません。代わりに、ERPをコンピューティングハードウェアを借りているデータセンターに配置することを意味します。私は、グローバルにデータセンターを持つ現代のクラウドコンピューティングプラットフォームの観点から見て、社内ホスティングとクラウドコンピューティングプラットフォームの間には実質的な違いはないと考えています。
本当に違いを生むのは、ERPがすべてのラウンドトリップを最小限に抑えるかどうかです。たとえば、ERPのパフォーマンスを低下させるのは、ビジネスロジックとリレーショナルデータベースの相互作用です。ウェブページを表示するために何度も行き来するような相互作用が数百回ある場合、ERPは非常に遅くなります。したがって、ラウンドトリップの数が多いエンタープライズソフトウェアの設計を考慮する必要があります。これは、見ているエンタープライズソフトウェアの内部プロパティであり、ソフトウェアの配置場所にはあまり依存しません。
質問: 新しいプログラミング言語が必要だと思いますか？それらはハードウェアの設計をコアレベルで受け入れ、ハードウェアアーキテクチャの機能を最大限に活用するべきですか？
はい、そうです。ただし、完全な開示として、私には利益相反があります。これはLokadがEnvisionで行っていることです。Envisionは、現代のコンピュータで利用可能なすべての処理能力を活用するのは難しいという観察から生まれましたが、パフォーマンスを考慮してプログラミング言語自体を設計すれば、難しくないはずです。それを超自然的にすることができます。そのため、サプライチェーンのためのプログラミングパラダイムなど、適切なプログラミングパラダイムを選び、それらの概念を取り入れたプログラミング言語を構築すると、ほぼ無料でパフォーマンスを得ることができます。
支払う代償は、PythonやC++のようなプログラミング言語ほど表現力がないことですが、サプライチェーンに関連するすべてのユースケースをカバーすることを受け入れる覚悟があれば、大幅なパフォーマンス向上を実現できます。それが私の信念であり、それがなぜ、たとえばサプライチェーン最適化の観点から見ると、オブジェクト指向プログラミングは何ももたらさないとも述べた理由です。
それどころか、これは基本的には基礎となるコンピューティングハードウェアと対立するパラダイムです。私はオブジェクト指向プログラミングがすべて悪いと言っているわけではありません。それは私が言っていることではありません。ソフトウェアエンジニアリングの一部の領域では完全に意味がありますが、サプライチェーンの予測最適化に関しては意味がありません。ですので、本当にそれを受け入れるプログラミング言語が必要です。
私はこれを繰り返す傾向があることを知っていますが、Pythonは実質的には80年代後半に設計されましたが、現代のコンピュータに関するすべての情報を見逃してしまいました。彼らはマルチスレッディングを活用することができないように設計されています。グローバルロックがあり、複数のコアを活用することができません。局所性を活用することができません。メモリアクセスを複雑にする遅延バインディングがあります。非常に変数的であり、多くのメモリを消費するため、キャッシュに対して悪影響を及ぼしますなど。
これらは、Pythonを使用する場合、今後数十年にわたって困難な戦いに直面することを意味します。そして、時間が経つにつれて戦いはますます激化するでしょう。彼らは改善されません。
次回の講義は3週間後、同じ曜日、同じ時間に行われます。6月9日のパリ時間の午後3時に行われます。サプライチェーンのための現代のアルゴリズムについて話し合います。それはサプライチェーンのための現代のコンピュータの対応物です。また次回お会いしましょう。
