アルゴリズムはコンピュータアーキテクチャに依存しますか？
アルゴリズムはコンピューターアーキテクチャーから独立していることをどこかで読んだ（どちらの本かは忘れた）。アルゴリズム自体が計算機であると言う人もいます（マシン？）？
一方、並列プログラミングに関する本には、並列アルゴリズムに関する章があります。並列アルゴリズムは並列アーキテクチャに依存しているようですか？
大きな写真が恋しいと思いますか？ありがとう。
アルゴリズムは、特定の問題を解決するために実行される一連のステップです。もしそうなら、問題を解決するためのレシピ。 「プログラム」ももちろん同じことをします。 「アルゴリズム」を使用して、特定の機械設計、プログラミング言語などに依存しない「一般化された」または「一般的に適用可能な」レシピを提案します。
アルゴリズムは一般的なものですが、それでも、存在するいくつかの機能に依存する可能性があります。たとえば、「並行アルゴリズム」は、さまざまなプログラムを同時に実行するためのメカニズムがあるかどうかに依存します。 「分散アルゴリズム」は、協力グループに複数のシステムがあること、およびそれらの間のネットワークまたはその他の通信方式に依存する場合があります。同様に、「並列アルゴリズム」は多くの場合、複数の処理ユニット（潜在的に多数、多数の処理ユニット）がある場合に実行するように設計されたものであり、処理ユニットの配列が大きい場合に一般的な種類の通信機能です。コンピューターまたはCPUが1つしかない場合でも「並列アルゴリズム」を実行できる可能性がありますが、道路がない限り交通エンジニアがあまり役に立たないという点でそれほど興味深いものではありません。
アルゴリズムはコンピュータアーキテクチャに依存しません。これは、アルゴリズムが問題を解決する一連のプロセスを定義するためです。アーキテクチャに関係なく、並べ替えアルゴリズムは常に並べ替えを行います。一部のアーキテクチャでは、3D図面が突然レンダリングされません。
考えてみれば、実は直感的です。 Google Chrome（これはアルゴリズムのコレクションにすぎません）は、任意のアーキテクチャ用にコンパイルされた場合のWebブラウザです。一部のアーキテクチャでは、突然デバイスドライバにならない場合があります。
ただし、アルゴリズムの実行速度はアーキテクチャによって異なります。また、アーキテクチャによっては、一部のアルゴリズムが他のアルゴリズムよりも高速に動作します。
考えてみれば、これも直感的です。アルゴリズムを考えると、ハードウェア設計者はそのアルゴリズムを特に高速化するアーキテクチャを設計することが常に可能です。これが、3Dアクセラレートグラフィックカードやビットコインマイナーアクセラレータなどがある理由の1つです。
人々が並列アルゴリズムについて話すとき、彼らは並列アーキテクチャでより速く動作することができるアルゴリズムのファミリーについて話しています。並列アーキテクチャによって改善されないアルゴリズムはたくさんあります。したがって、並行してうまく機能する同じ問題の新しいアルゴリズムを特定することは、活発な研究分野です。
しかし、それらのアルゴリズムはまだ同じことを行います。アーキテクチャは、それらが何をするかを変えません。
「並列アルゴリズムは並列アーキテクチャに依存しているようですか？」
私の意見では、答えは単純です：いいえ。一般私はプロパティのみを取得します
- 平行性
- ワードサイズ（暗黙のリソース制限）
ハードウェアアーキテクチャについて考えるとき。
並列処理を参照すると、任意の並列アルゴリズムをバッチ計算し、任意の並列Archを逐次動作させることができるため、アルゴリズムはそれに依存しません。ワードサイズは、数値の安定性の問題ではあるが、アルゴリズム自体の問題ではない場合があります。 64ビットのようなリソース制限では2 ^ 64の異なる数値しか記述できないため、問題が発生する可能性がありますが、要素は制限されています。
もちろん、いくつかの拡張命令セットに依存するいくつかのアルゴリズムがあるかもしれませんが、少なくともすべてが基本的な数学で記述できます。
たとえば、量子コンピューティングでは、いくつかのBig-O値が変化する可能性があります。
「アルゴリズムはコンピュータアーキテクチャに依存しない」
もう本当ではありません。
アルゴリズムはコンピュータアーキテクチャに依存しませんが、特定のアルゴリズムを実行する効率はアーキテクチャに依存します。チューリングコンプリートマシンは、他のチューリングコンプリートマシンをエミュレートできます。
コンカレントアルゴリズムとは、アルゴリズムが適切に機能するか、マシンでの同時実行性を利用できるということです。おそらく、同時実行マシン用に特別に設計されていないアルゴリズムが必要とするよりも少ないロックが必要なためか、アルゴリズムは、分割と征服を効果的に使用して、マシンの全能力を使用します。並行していないマシンでアルゴリズムを実行することも可能ですが、効率が悪くなるか、正しく実行するために追加のロックが必要になる場合があります。
キャッシュを最適化するキャッシュフレンドリーなアルゴリズムなど、特定のアーキテクチャの癖を利用するように設計されたアルゴリズムもあります。これらのアルゴリズムは、アルゴリズムが想定する方法をキャッシュしないマシンでは効率が低下する可能性があります。
理論的には、アルゴリズムはアーキテクチャから完全に独立しています。単一の問題のタイムスライスされたシステムでは、常に並列アーキテクチャをエミュレートできます。アーキテクチャのないアルゴリズムについては理由でできます。クヌースの本は架空のアーキテクチャを使用しています。
実際には、キャッシュハードウェアと同期プリミティブの使用を最適化することにより、同じ「O」の複雑さに対してより優れたランタイムを達成しようとするアルゴリズムがあります。
はい、いいえ満たす制約に依存し、アルゴリズムの実行に必要な前提条件.
理想的には、アルゴリズムは抽象的なレシピであり、何かを行う方法を段階的に定義します。アルゴリズムは、再現性とその後の自動化を目的としてそのように定義されました。アルゴリズムはラムダ計算に由来しているため、このような方法で作成された理由を簡単に確認できます。この定義は通常のものですが、最新のアルゴリズムは非順次（同時アルゴリズムのような段階的なものではなく、統一を使用するような論理的なもの）、非線形（確率的アルゴリズム）、またはまったく奇妙なもの（量子アルゴリズム）、しかし私はそれを渡します。
したがって、理想的には、アルゴリズムはハードウェアを考慮せずにできるだけ抽象的である必要があります。
しかし、他のシステムと同様に、一貫したシステムを取得するだけでなく、時間を稼ぐためにも、いくつかのaxiomsを定義する必要があります。たとえば、ほとんどのアルゴリズムは、少なくとも暗黙的に、それらがフォンノイマンマシンで定義されていると想定しています。そうでない場合は、実行する必要があるシステムの各部分を明示的に定義する必要があります（これはレシピを再現するために必要なので、これは一種の前提条件です）。また、多くの場合、アルゴリズムは完全に定義せずに、write（）などの一般的なコマンドに依存しています。
アルゴリズムがハードウェアアーキテクチャからそれほど抽象的でないもう1つの理由は、いくつかの制約を満たす必要があるときです。
組み込みシステムで作業しているとしましょう。ワークステーションと同じ量のリソースに依存することはできないでしょう。最も抑制されているリソースの1つは、おそらくメモリです。ただし、ほとんどのアルゴリズムは、メモリの複雑さ（データの処理に必要なメモリの量）ではなく、時間の複雑さ（CPUでの実行速度）を最適化する傾向があります。これらのシステムでは、メモリ最適化アルゴリズムが考案されており、非メモリ最適化アルゴリズムは失敗するか、実行速度が大幅に低下します。実際、組み込みシステムはメモリ効率の高いアルゴリズムの唯一のターゲットではありません。たとえば、CPUキャッシュを効率的に使用するように処理を適応させる cache-oblivious algorithm があります。別の例：ビッグデータの一部の機械学習アルゴリズムは インクリメンタルラーニングまたはコア外コンピューティング 用に調整されており、コンピューターなどで利用可能なメモリよりもはるかに大きい大量のデータを処理します。
コンピュータの特定の部分を最適化しないアルゴリズムもありますが、ハードウェアアーキテクチャに依存する標準があります。たとえば、精度を必要とする数値データはfloatまたはdoubleの内部に格納されますが、これらはハードウェアの制限により本質的に制限されています。問題は、複雑な計算は丸めにつながる可能性があり、丸められた数値に対して実行する計算が多いほど、ドリフトが大きくなることです。これは 致命的な干渉 と呼ばれます。一部のアプリケーションでは、最悪の複雑さを犠牲にしても、重要な精度が必要です。このタイプのアプリケーションでは、壊滅的な干渉を低減または削除するために計算を最適化するアルゴリズムが作成されました。
したがって、アルゴリズムの設計は、抽象化と制約の間のトレードオフにもなります。
結局のところ、アルゴリズムはそのターゲットと同じくらい抽象的であり、その前提条件（アーキテクチャ）のニーズと同じであると言えます。アルゴリズムのターゲットが具体的であればあるほど、ハードウェアアーキテクチャに依存する可能性が高くなります。
興味があるかもしれないいくつかの関連キーワード：
一般的なアルゴリズムと数学または計算アルゴリズムを混同しないでください。コンピューティングアルゴリズムを意味している場合、はい、それらはマシンアーキテクチャから独立しています。
ウィキペディアのアルゴリズムの定義：
数学およびコンピュータサイエンスの場合、アルゴリズムは、実行する必要のある操作の自己完結型の段階的なセットです。 計算、データ処理、および自動推論を実行するアルゴリズムが存在します。
この定義は、いくつかの閉じた計算またはデータ処理タスクを参照するために使用されます。つまり、抽象的にTuring Machineで実行できる計算です。ただし、最近、数学には インタラクティブ計算 という名前の概念があり、これは外部世界との入出力通信中の計算を伴います。
一般的な定義では、アルゴリズムは単なるレシピ（命令のシーケンス）です。使用できる命令セットや演算を知らないと、アルゴリズムを考えることはできないと思います。数学的操作は計算に関するものであり、「heat up theオーブン」という名前のステップを含むアルゴリズムは数学的アルゴリズムではありませんが、シェフが知っているので、それをシェフに与えることができますそれを実行します。
次に、X、Y、Zなどを実行できるマシンを作成できます。これらのそれぞれをアルゴリズムとして命令として使用できます。しかし、それらがすべて閉じた計算（実際、非対話型の確定的デジタル小ステップ計算）に関するものである場合、[このマシンはTuring Machineと同等であることが証明できます。しかし、他のタイプの計算（継続値または インタラクティブな計算 [ただし、それらが本当に別のタイプの計算であるかどうかはわからない]）または非計算タスクさえ対象とする場合、マシンを考えることができますそれらを実行できます。
この質問と answer は、アルゴリズムについて広い視野を得るためにも興味深いものです。
一般に、アルゴリズムは、「コスト」の測定値を最小限に抑えながら、特定の問題に合わせて設計されています。歴史的に、多くのアルゴリズムは、一般的な操作の相対コストが多くのアーキテクチャで比較的類似していると想定して設計されていたため、一部の典型的なマシンは1つのアルゴリズムを実行し、ほとんどの典型的なマシンでは前のアルゴリズムを実行しました。最悪の場合、後者よりわずかに劣るだけです。時が経つにつれ、そのような仮定は以前ほどには成り立たなくなります。
たとえば、以前は、プログラムがメモリから物を読み取るのに必要な回数が、読み取られる物の位置よりも重要であると考えられていました。記憶の中で互いに近くにあるものを読むことは、遠く離れているものを読むことよりもいくらか安くなりましたが、とんでもないことではありません。ただし、メインCPUの速度がメモリ速度をはるかに超える速度で増加しているため、アクセスシーケンスの重要性が大幅に増加しています。前のプログラムのメモリフェッチの95％がL1キャッシュヒットを生成し、後者のプログラムのメモリフェッチの大部分がキャッシュミスを生成する場合、1つのプログラムで別のプログラムの10倍の命令を実行し、それでもより高速に実行できます。
さらに、特定の種類の同時実行関連アルゴリズムは、1つのプロセッサコアによってメモリに書き込まれたデータが他のコアによって「認識」されるタイミングについてさまざまな仮定を行います。多くのプロセッサには、メモリの読み取りと書き込みを行うさまざまな方法があり、可視性に関するさまざまなコストと保証があります。一部のアルゴリズムは、「無料」で可視性の要件を満たすことができるアーキテクチャで非常にうまく機能しますが、それらの保証に必要な命令が高価な他のアルゴリズムでは不十分です。実際、一部のアーキテクチャでは、特定の同時実行性に関連するアルゴリズムは、実行を単一の時分割CPUコアに限定することによってのみ動作することが保証されます（もちろん、同時アルゴリズムの使用のポイントを無効にします）。
アルゴリズムは、アーキテクチャから抽象的または直接的な文字通りの関係で定義できるという事実を見逃している回答がたくさんあります。アルゴリズムは明確でなければなりませんが、多少具体的にする余地はまだあります。
文字列をすべて大文字に変換するアルゴリズムは、アーキテクチャに依存しない疑似コードで簡単に記述できます。ただし、同時にnothingを使用すると、特にx86アーキテクチャで文字列をすべて大文字に変換するアルゴリズムを記述できなくなります。必要なのは、x86アセンブリの宿題です。 （これは疑似コードで行うことができます-そのアーキテクチャに関連する疑似コードだけです！）問題がx86アーキテクチャで特にこれを行うためのものであるという事実は、それを解決するアルゴリズムがないことを意味しません。
アルゴリズムが解決するように定義されている問題によって異なります。アルゴリズムが解決する問題がアーキテクチャに依存しない場合、アルゴリズムはアーキテクチャに依存しません（これは、アルゴリズムの記述またはまとめ方によって元に戻されないと想定されています）。問題は、理論上の黒板の問題である場合と、非常に特殊なアーキテクチャの問題である場合があります。後者の場合、アルゴリズムはそのアーキテクチャでの作業に限定されます。
アルゴリズムは一連のステップです。それらは、何を実行している（または実行していない）かには依存しません。
ただし、アルゴリズムの時間の複雑さは実行されているものに依存しますそれ。そのため、アルゴリズムの詳細な分析には、 ランダムアクセスマシン などの「計算モデル」が必要です。
メモリがランダムにアクセス可能かどうかは、アルゴリズムの実行にかかる時間に確実に影響します。ほとんどのアルゴリズムは、これが当てはまると想定していますが、実際には、ほとんどのアーキテクチャはこの条件を満たしていません。
問題の状況によって異なります。アルゴリズムは、問題を解決するための一連のステップです。この問題のコンテキストは、理論的には何でもかまいません。したがって、問題を解決するアルゴリズムは、文字通り、私たちが想像できる宇宙上のあらゆるものに依存する可能性があります。例を挙げて説明します。あなたがタスクを与えられているとしましょう、
マルチコアが利用可能な場合に、複数のコアに負荷を分散するアルゴリズムを構築します。
ここで、アルゴリズムがアーキテクチャに依存するかどうかを想像できますか？もちろんyesです。