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


9

すみません、私の混乱した質問のために。ポインタを探しています。

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

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

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

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


1
これへの素晴らしい答えがあります(質問への最初の)プログラマー
.stackexchange.com / questions / 81624 /…

攻撃と悪用はすべてのレベルで発生する可能性があります。脆弱なPHPスクリプトを作成すると、ハードウェアはもちろん、基盤となるOSに関係なく悪用される可能性があります。
tdammers

1
トピックに関する素晴らしい本を見つけました:コンピューティングシステムの要素:第一原理から現代のコンピューターを構築するNoam Nisan、Shimon Schocken。このアプローチに関する
ショッケン

dosの時代には、VGAグラフィックルーチンにアセンブリ言語を使用することが、パフォーマンスを得る唯一の方法でしたが、自分が何をしているのかわからなかったと思います。しかし、私のキャリアのこの10年以上の間、私はそれほど低いものを見る必要はありませんでした。そして今、私はそれらのレベルで何が起こるかについてほとんど無知です。まれに、自分のメモリを割り当てたりクリーンアップしたりする必要さえあります。私のチームの多くはスタックが何であるかを知らないのではないかと思います!多くの点で、そのようなレベルでコーディングすることは生産的ではなく、いわば車輪を再発明します。むしろ私たちは巨人の肩の上に立ちます。
Gavin Howden 2012年

回答:


19

これらについて考えるキーワードは抽象化です。

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

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

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

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

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


1
まことにありがとうございます。したがって、ガベージコレクション/メモリ管理の例は、おそらくこの相互作用の最もよく知られている例です。ニールガーシェンフェルドはいくつかの興味深いものを書きましたが、私はその一部しか理解していません。
RParadox

...複雑さについて非常に良い点。機械だけが私たちの機械を設計できる場合、これはどこにつながりますか?AIの人々がAIについて話し、よりスマートなAIを作成しているなら、おそらく私たちもそこにいるでしょう。;)
RParadox
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.