コンピューティングのレベルを理解する

Question

すみません、私の混乱した質問のために。いくつかの指針を探しています。

これまでは、主にアプリケーション層でJavaおよびPythonを使用して作業しており、オペレーティングシステムとハードウェアについて漠然とした理解しかありません。より低いレベルのコンピューティングについてはもっと理解できますが、どういうわけか本当に圧倒されます。大学では、マイクロプログラミング、つまりプロセッサーがASMコードを実装するためにどのようにハードワイヤードされているかについてクラスを受講しました。これまでは、「低レベル」についてもっと学べば、もっとできる。

私の質問の1つは、ハードウェアが開発者からほぼ完全に隠されてしまう可能性はあるのでしょうか。オペレーティングシステムはハードウェアのソフトウェア層であると言っても間違いありませんか？ 1つの小さな例：プログラミングで、L2キャッシュまたはL3キャッシュとは何かを理解する必要に遭遇したことはありません。典型的なビジネスアプリケーション環境の場合、アセンブラーや下位レベルのコンピューティングを理解する必要はほとんどありません。現在、ほとんどすべてのテクノロジースタックが存在するためです。これらの低レベルの全体のポイントは、高レベルへのインターフェースを提供することだと思います。一方で、たとえばこのグラフィックスコンピューティング全体など、下位レベルがどの程度の影響を与える可能性があるのでしょうか。

そのため、一方で、この理論的なコンピュータサイエンスブランチがあり、抽象的なコンピューティングモデルで動作します。ただし、複雑なモデルや証明の検証などのカテゴリで役立つ考えを見つけたという状況にもめったに遭遇しませんでした。私は、NPという複雑なクラスがあり、それらを解決するのがある程度不可能であることを知っています。多数のN.私が見落としているのは、これらのことを考えるためのフレームワークのリファレンスです。私には、ほとんど相互作用しないさまざまなキャンプがあるようです。

過去数週間、セキュリティの問題について読んでいました。ここでは、どういうわけか、さまざまなレイヤーの多くが一緒になっています。攻撃とエクスプロイトはほとんど常に下位レベルで発生するため、この場合は、OSIレイヤーの詳細、OSの内部動作などについて知る必要があります。

Kilian Foth · Accepted Answer

これらについて考えるためのキーワードはabstractionです。

抽象化とは、システムの詳細を意図的に無視することを意味し、多数のサブシステムからより大きなシステムを組み立てるときに、それを単一の不可分なコンポーネントと考えることができます。それは想像を絶するほど強力です-メモリ割り当ての詳細を考慮しながら最新のアプリケーションプログラムを作成するandレジスタの流出andトランジスタランタイムは、理想的な方法で可能ですが、比類なく簡単ですnotそれらについて考え、代わりに高レベルの操作を使用します。現代のコンピューティングパラダイムは、ソリッドステートエレクトロニクス、マイクロプログラミング、機械命令、高水準プログラミング言語、OSおよびWebプログラミングAPI、ユーザーがプログラム可能なフレームワークとアプリケーションなど、抽象化の複数のレベルに大きく依存しています。今日、システム全体を理解することは事実上不可能であり、その状況に戻ることができるとは考えられない道すらありません。

抽象化の裏側は、力の喪失です。詳細についての決定を下位レベルに任せることにより、下位レベルには「全体像」がなく、ローカルの知識によってのみ機能を最適化でき、（潜在的に）ではないため、それらは次善の効率で行われる可能性があることをしばしば受け入れます。人間としてインテリジェント。（通常、プロセッサのアーキテクチャが非常に複雑になったため、HLLをマシンコードにコンパイルすることは、今日ではよく行われますbetter最も知識のある人間よりもマシンによって。）

セキュリティの問題は興味深い問題です。抽象化の欠陥や「漏洩」がシステムの整合性を侵害するために悪用されることがよくあるからです。 APIがメソッドA、B、およびCを呼び出すことができると想定しているが、条件Xが成立する場合にのみ、条件を忘れて、条件に違反したときに発生するフォールアウトに備えることができません。たとえば、従来のバッファオーバーフローは、この特定のメモリブロックを自分で割り当てない限り、メモリセルへの書き込みが未定義の動作をもたらすという事実を悪用します。 APIはsomethingが結果として発生することのみを保証しますが、実際には、結果は1つ下のレベルのシステムの詳細によって定義されます。条件を満たす限り、これは重要ではありませんが、そうでない場合でも、両方のレベルを密接に理解している攻撃者は、通常、システム全体の動作を必要に応じて指示し、悪いことを引き起こす可能性があります。

大規模なシステムで単一のエラーなしに手動でメモリを管理することは実際には非常に難しいことが判明したため、メモリ割り当てのバグの場合は特に悪いです。これは、抽象化の失敗例と見なすことができます。Cmalloc APIを使用して必要なすべてのことを実行できますが、悪用するのは簡単です。プログラミングコミュニティの一部は、これがシステムにレベル境界を導入するのに不適切な場所であると考え、代わりに自動メモリ管理とガベージコレクションを使用して言語を促進しますが、ある程度の能力は失われますが、メモリの破損と未定義の動作に対する保護を提供します。実際、現在でもC++を使用している主な理由は、どのリソースをいつ取得および解放するかを正確に制御できることです。このように、今日のマネージ言語とアンマネージ言語の間の主要な分裂は、抽象化の層を正確に定義する場所についての不一致と見なすことができます。

コンピューティングにおける他の多くの主要な代替パラダイムについても同じことが言えます。今日の一般的な複雑な要件のためにソリューションをゼロから設計することはできないため、大規模なシステムを構築しなければならない場合は常に問題が発生します。（最近のAIの共通の視点は、人間の脳が実際にdoesのように機能することです-フィードバックループ、大規模に相互接続されたネットワークなどを通じて発生する動作で、モジュール間に単純で抽象化されたインターフェースを持つ個別のモジュールやレイヤーではありません。、そしてそれが、私たち自身の知性のシミュレーションにほとんど成功していない理由です。）