コンピュータアーキテクチャを理解すると、プログラマはどのように役立ちますか？
Mike P. Wittieによると、コンピュータアーキテクチャの コースカリキュラム では、
学生は、プログラムを実際のマシンでより効率的に実行できるようにプログラムを構成するために、コンピュータアーキテクチャを理解する必要があります。
このトピックの背景を持つ、より経験豊富なプログラマーまたは専門家にお願いします。
コンピュータアーキテクチャの学習はどのように役立ちますか？最もメリットがあるのはどのような点ですか？コンピュータアーキテクチャを学ぶことで、プログラミングの構造はどのように変わりましたか？
物理を理解することは、人々が車を運転するのにどのように役立ちますか？
- 彼らはブレーキフェードのような現象を理解し、それを補正します。
- 彼らは重心とタイヤがどのように路面をグリップするかを理解しています。
- 彼らはハイドロプレーニングとそれを回避する方法を理解しています。
- 彼らはどのようにカーブに出入りするのが最も良いかを知っています。
- 彼らはテールゲートする可能性がはるかに低い。
等々。あなたは物理学についてあまり知らなくても車を運転することができますが、物理学を理解することはあなたをより良いドライバーにします。
コンピュータアーキテクチャの理解がコーディング方法にどのように影響するかを示す2つの例：
これは基本的に、Cとポインター、またはアルゴリズムさえ理解するのと同じ理由です。唯一の違いは、コンピュータアーキテクチャを知っている場合は、ポインタを本当に理解していることです（実際、ポインタは、コンピュータアーキテクチャを知った後は非常に簡単なように見えます）。
私は経験豊富なプログラマーだとは言えませんが、私が読んだコンピュータアーキテクチャに関する（実際には）本は、コンピュータとプログラミングに関連して読んだ中で最も興味深い本でした。コンピュータアーキテクチャを理解することで、基本的にすべてがどのようにリンクされているか、コンピュータがどのように機能するか、プログラムが実際にどのように機能するかを理解できます。全体像がわかります。コンピュータアーキテクチャがないと、本当に理解できません。
- メモリ管理：ヒープ、スタック、仮想メモリ、メモリ階層、およびポインタについて話されている（スタックオーバーフローがある理由、再帰があまりよくない理由など）
- アセンブリプログラミング（組み込みプログラムを作成する場合）
- コンパイラーとインタープリター（最適化を理解したい場合、およびコンパイラーによって既に作成されているため、コードを最適化することが役に立たない場合）
- リンカー（動的にリンクされたライブラリ）
- オペレーティングシステム（Linuxカーネルコードを読みたい場合）
- リストは続くことができます...
私の本当に主観的な観点から見ると、アルゴリズムを知るよりもはるかに興味深く、多分さらに有用です。
今日の世界では、この推論がほとんどのプログラミング状況に存在する場合、無視できます。
適用できる場所は、特定のプロセッサ用のアセンブリを作成しているとき、特定のアーキテクチャを利用する必要がある状況で作業しているとき、または前の2つのポイントがすべてになるようにアーキテクチャ（組み込みシステム）によって大幅に制限されている場合です。より重要です。
インタープリター型言語（Perl、python、Ruby）または独自の仮想マシン（Java、C＃）で実行される言語のプログラマーは、基盤となるマシンを完全に抽象化します。 A Javaプログラムは、大規模なクラスターまたはデスクトップで実行するように別の方法でコーディングすることはできません。
前述のようにアーキテクチャが違いをもたらすのは、その環境に関する非常に低いレベルの懸念事項を考慮する必要がある組み込みシステムです。もう1つの極端な方法も存在します。1つは、アセンブリまたはネイティブコードにコンパイルされた（仮想マシンでは実行されていない）高性能コードを記述している場合です。これらの極端な例では、プロセッサキャッシュに適合するもの、およびメモリのさまざまな部分へのアクセスがどれほど高速であるか、プロセッサの分岐予測がどのように行われるか（プロセッサがすべてまたは遅延スロットで分岐予測を使用する場合）が懸念されます。
分岐予測と遅延スロットまたはプロセッサキャッシュの問題は、プログラミングの問題の大部分に関係することはなく、cannotはインタプリタ言語または仮想マシン言語に入ります。
そうは言っても、既存のコードが書かれているレベルよりも深いレベルで何が起こっているのかを理解することは有用です。それを超えると急速に収益が減少します。 A Javaプログラマは、内部で何が行われているのかを理解するために、手動のメモリ管理とポインタ計算を使用してプログラミング言語を理解する必要があります。ACプログラマは、どのポインタを理解できるようにアセンブリを理解する必要があります本当にあり、どこにメモリがあるか本当にが付属しています。分岐予測と遅延スロットのトレードオフが何を意味するかを理解し、それをさらに進めるために、アセンブリコーダーはアーキテクチャに精通している必要があります。プロセッサの設計は、半導体とゲートが非常に基本的なレベルでどのように機能するかについて、量子力学に精通している必要があります。
私は、コンピュータの構成を理解していない人はだらしないプログラマーになる運命にあるとまで言っています。あなたは知っているでしょう：
- キャッシュ効率を高めるためにデータ構造とアルゴリズムを整理する方法
- 関数呼び出しがどのように機能するか、および呼び出し規約への影響
- メモリのセグメント、および変数宣言への影響
- アセンブリの読み取り方法、つまりコンパイラの出力の解釈方法
- 命令レベルの並列処理と順不同の命令スケジューリングの影響、およびそれが分岐にとって何を意味するか
基本的には、コンピューターが実際にどのように機能するかを学習するため、コードをより効果的にマップすることができます。
2018年更新：電球を変更するには、何人のソフトウェア開発者が必要ですか???誰も気にしない！？それはハードウェアの問題です！
一般的にいいえ、優れたプログラマになるためにコンピュータアーキテクチャを知る必要はありません。もちろん、それがEE領域IMOの詳細です。組み込みシステムの開発に携わっていますが、その場合はチップと結婚していて、その上でプログラミングしているので、その「コンピュータ」のアーキテクチャを知る必要があります（それでも問題にならない場合もあります）。コンピューターがどのように機能するかについての一般的なアーキテクチャーの理解は、ウォーターホールの議論以外にはあまり役立ちません。
最近では、ハードウェアの価格が低下し、パフォーマンスが向上/向上していること、およびテクノロジーの変化と言語の進化の速さという点で、それほど重要ではないと思います。私の知る限り、データ構造とデザインパターンは、物理的なハードウェアアーキテクチャとはあまり関係がありません。
一般的に、プログラマーはコンピューターサイエンスのバックグラウンドを持っています。その場合、コンピューターアーキテクチャのクラスを取得する可能性が高くなりますが、最近では、オペレーティングシステムは仮想化され、ディスクスペースは共有され、メモリはスケーラブルになります。 ..
私はプログラミング（10年以上）で素晴らしいキャリアを積むことができ、コンピュータアーキテクチャに関する教育知識はほとんどありません。
更新：公正を期すために、私の「小さな教育知識」は私のCPU Sciから来ました。マイナー。それでも、「プログラミング」のキャリアで、アセンブリクラスやコンピュータアーキテクチャクラスから学んだことを使う必要はまったくありませんでした。
ZigBee 仕様を実装するメッシュネットワーキングのアイデアをいじってみても、利用可能な製品とツール（ XBee ）を使用することで、 Python でプログラムし、コードをチップ（SoC）に直接配置して、実際にきちんとした処理を行います..ALL実際の処理とは関係ありません。チップのアーキテクチャなど..チップサイズと意図された低価格ターゲットのために、認識すべきハードウェアの制限は確かにありますが、それでも次の年には少なくなります。 だから私は私の「一般的にいいえ」の答えを支持します
コンピュータアーキテクチャの原理を理解するには、プログラミングの多くの重要な原理を学ぶ必要があります。したがって、コンピュータアーキテクチャの知識は、どんなに高いレベルでも、あらゆる言語でのプログラミングに関連しています。
これらの重要な原則は次のとおりです。
- 配列やスタックのような基本的なデータ構造
- プログラムの構造：ループ、条件、サブルーチン（ジャンプと呼び出し）
- 時間とスペースの効率に関する考慮事項
- システム：さまざまなコンポーネントが抽象的なインターフェースを介して互いに適合する方法。どうやらこれは物議を醸しているので、詳しく説明します。算術、論理、メモリ変更、割り込み制御など、さまざまな種類の演算に適用できる一般的な形式（オペランド、アドレッシングモード、エンコーディング）を持つ構成体である命令セットを取り上げます。これは、システム設計の一般原則を示しています。つまり、システムはすべて同じ抽象インターフェースを共有する個々のサブシステムで構成されており、抽象インターフェースは多くの特定のコンポーネントを処理できます。この原理は、同じ種類のオブジェクト（抽象インターフェイス）をデータベース、メモリ、またはWebページ（サブシステム）に格納するWebアプリケーションでも表示されます。いずれの場合も、抽象インターフェースは具体的な詳細を指定せずに一般的なフォームを指定します。システム設計とは、一般的に何を作成し、具体的に何を作成するかを知る技術です。これは、システムを設計し、理解することにより、あらゆる言語で、あらゆるレベルで磨かれたスキルです。
実際にはかなり役立ちます。共有メモリやプロセッサ間通信などの概念と、これらに関連する潜在的な遅延を理解すると、プログラマがデータや通信方法を調整して、必要に応じてこれらのメカニズムに大きく依存することを回避できます。これは、水平スケーリングなどの他のプログラミング領域にも当てはまり、プログラムまたはプログラムシステム間の配布と通信が主な焦点となります。
物理システムの落とし穴やタールピットを理解すると、そのようなプログラムを準備して、物理システムの交渉をできるだけ迅速かつ効率的に行うのに役立ちます。データを通信キューに投入してスケーリングすることを期待するだけで、特にサポートを強化するためにソフトウェアをより大きなシステムにスケーリングする必要がある場合は、実際に何を配置する必要があるかがわかりません。
同様に、関数型プログラミングなどの利点を理解することは、物理的なシステムレベルで何が起こっているのかを理解するという観点から実際に例示でき、これらの概念の牽引力をさらに高めると私は考えています。
最後の簡単な例の1つは、ストリーム処理の概念を理解し、ビデオカードなどの処理ユニットにデータを送信する方法が、次のような非常に特殊な方法で最善の方法で行われる場合があることを理解することです。データが一気に急降下しました。ビデオグラフィックスや物理計算のようなものでは、そのようなデバイスとの継続的な通信を継続する必要はありません。したがって、これを知っている場合は、プログラムのこの部分をそのように配置する必要があります。
結局のところ、プログラマがこれらの問題と障害を理解していなければ、これらのソリューションは彼らがするような形式では決して存在しないでしょう。
アーキテクチャを知ることで、求められていることが不可能である場合を知ることができます。
私はかつて、PCシリアルポートを介してPICと通信するプログラムを作成するように求められました。このプロトコルでは、PICはフロー制御なしで9ビットバイトを送信します。プログラムのUIに、PICが送信したパケットのフィールドの値を表示します。明白な質問：各バイトの9番目のビットをどのように読み取るのですか？プロトコルエンジニアと私は、パリティをMARKに設定してから、9番目のビットをパリティビットとして扱うことを決定しました。パリティチェックの成功または失敗に応じて、9番目のビットの値を読み取ります。まあ、私はそれを実装しましたが、うまくいきませんでした。表示されている値は明らかに間違っていました。そして、PC UART=アーキテクチャーを研究し続けて3日後、私はその理由を発見しました。
これが理由です。 PC UARTはその入力をバッファリングします。CPUに割り込んで「READY TO READ」と表示するまでに、任意の数のバイトがバッファに蓄積されている可能性があります。ただし、1行しかありません。パリティチェックの値を保持するためのステータスレジスタ。したがって、バッファのどのバイトがパリティチェックに失敗したかを特定することはできません。つまり、バッファの長さが1バイトのみであることを確認しますか？これはフロー制御設定です。このプロトコルにはフロー制御がないことを既に述べました。プログラミングしているハードウェアのアーキテクチャがわからなければ、「9番目のビットを読み取ることは不可能であり、カットする必要があります。 」