アルゴリズムはコンピューターアーキテクチャに依存しますか？

アルゴリズムはコンピューターアーキテクチャに依存しないことをどこかで読みました（どの本かを忘れました）。アルゴリズム自体が計算であると言う人もいます（マシン？）？

一方、並列プログラミングに関する本には、並列アルゴリズムに関する章があります。並列アルゴリズムは並列アーキテクチャに依存しているように見えますか？

大きな写真が恋しいですか？ありがとう。

アルゴリズムは、特定の問題を解決するために実行される一連の手順です。問題を解決するためのレシピ。もちろん、「プログラム」は同じことを行います。「アルゴリズム」を使用して、特定の機械設計、プログラミング言語などに依存しない「一般化された」または「一般的に適用可能な」レシピを提案します。

アルゴリズムは一般的であるように意図されていますが、まだ存在するいくつかの機能に依存する可能性があります。たとえば、「コンカレントアルゴリズム」は、異なるプログラムが同時に実行されるメカニズムがあるかどうかに依存する場合があります。「分散アルゴリズム」は、協力するグループに複数のシステムがあること、およびそれらの間のネットワークまたは他の通信スキームに依存します。同様に、「並列アルゴリズム」は、多くの場合、複数の処理ユニットがある場合に実行されるように設計されたものです。処理ユニットの数が多い場合、処理ユニットの配列が大きい場合に一般的な通信機能があります。コンピューターまたはCPUが1つしかない場合でも「並列アルゴリズム」を実行できる場合がありますが、トラフィックエンジニアがいるという点ではそれほど面白くありません」

アルゴリズムはコンピューターアーキテクチャに依存しません。これは、アルゴリズムが問題を解決する一連のプロセスを定義するためです。アーキテクチャに関係なく、ソートアルゴリズムは常にソートされます。一部のアーキテクチャで3D図面が突然レンダリングされることはありません。

考えてみれば、これは実際には直感的です。Google Chrome（単なるアルゴリズムのコレクション）は、あらゆるアーキテクチャ向けにコンパイルされたWebブラウザです。一部のアーキテクチャでは、デバイスドライバーになることはありません。

ただし、アルゴリズムの実行速度はアーキテクチャによって異なります。また、一部のアルゴリズムは、アーキテクチャに応じて他のアルゴリズムよりも高速に動作します。

考えてみると、これも実際には直感的です。アルゴリズムが与えられると、ハードウェア設計者は、そのアルゴリズムを特に高速化するアーキテクチャを設計することが常に可能です。これが、3Dアクセラレーショングラフィックスカードやビットコインマイナーアクセラレータなどが存在する理由の1つです。

人々が並列アルゴリズムについて話すとき、彼らは並列アーキテクチャ上でより速く動作することができるアルゴリズムのファミリーについて話している。並列アーキテクチャによって改善されていないアルゴリズムはたくさんあります。したがって、同じ問題に対して並行してうまく機能する新しいアルゴリズムを特定することは、活発な研究分野です。

しかし、これらのアルゴリズムはまだ同じことを行います。アーキテクチャは、何をするかを変えません。

「並列アルゴリズムは並列アーキテクチャに依存しているように見えますか？」

私の意見では、答えは単純です：いいえ。一般プロパティのみを取得します

• 平行度
• ワードサイズ（暗黙的なリソース制限）

ハードウェアアーキテクチャを考えるとき。

並列性を参照すると、任意の並列アルゴリズムをバッチ計算し、並列アーチを直列に動作させることができるため、アルゴリズムはそれに依存しません。ワードサイズは、数値の安定性の問題ではありますが、アルゴリズム自体の問題ではない場合があります。64ビットのようなリソース制限では、2 ^ 64の異なる数値しか記述できない場合がありますが、とにかく要素は限られています。

もちろん、いくつかの拡張命令セットに依存しているアルゴリズムもありますが、少なくともすべては基本的な数学で説明できます。

たとえば、量子コンピューティングでは、一部のBig-O値が変化する可能性があるため、

「アルゴリズムはコンピューターアーキテクチャに依存しない」

もう真実ではありません。

アルゴリズムはコンピューターアーキテクチャに依存しませんが、特定のアルゴリズムを実行する効率はアーキテクチャに依存します。Turing Completeマシンは他のTuring Completeマシンをエミュレートできますが、一部のマシンは他のマシンよりも優れている場合があります。

並行アルゴリズムとは、並行マシン用に特別に設計されていないアルゴリズムに必要なロックが少ないため、またはおそらくアルゴリズムは、分割と征服を効果的に利用して、マシンの全能力を使用します。非並行マシンでアルゴリズムを実行することも可能ですが、効率的ではないか、正しく実行するには追加のロックが必要になる場合があります。

キャッシュを最適化するキャッシュフレンドリーアルゴリズムなど、特定のアーキテクチャの癖を利用するように設計されたアルゴリズムもあります。これらのアルゴリズムは、アルゴリズムが想定する方法をキャッシュしないマシンでは効率が低下する場合があります。

理論的には、アルゴリズムはアーキテクチャから完全に独立しています。単一発行のタイムスライスシステムで、常に並列アーキテクチャをエミュレートできます。あなたはできる理由すべてのアーキテクチャなしのアルゴリズムについて。Knuthの本は、架空のアーキテクチャを使用しています。

実際には、キャッシュハードウェアと同期プリミティブの使用を最適化することにより、同じ「O」の複雑さに対してより良いランタイムを達成しようとするアルゴリズムがあります。

はいといいえ。それはあなたが満たしたい制約とアルゴリズムを実行するために必要な前提条件に依存します。

理想的には、アルゴリズムは、何かを行う方法を段階的に定義する抽象的なレシピです。アルゴリズムは、再現性とその後の自動化を目標に、そのように定義されました。アルゴリズムはラムダ計算に由来するため、そのような方法で作成された理由を簡単に確認できます。この定義は通常のものですが、現代のアルゴリズムは非シーケンシャル（同時アルゴリズムのような段階的ではなく、統合を使用するような論理的なものではありません）、非線形（確率的アルゴリズム）または単に奇妙（量子）アルゴリズム）、しかし、私はそれを渡します。

したがって、理想的には、アルゴリズムはハードウェアを考慮せずにできるだけ抽象的である必要があります。

しかし、他のシステムと同様に、一貫したシステムを取得するだけでなく、時間を稼ぐために、いくつかの公理を定義する必要があります。たとえば、ほとんどのアルゴリズムは、少なくとも暗黙的に、フォンノイマンマシンで定義されていることを前提としています。そうでない場合は、実行する必要のあるシステムの各部分を明示的に定義する必要があります（レシピを再現するために必要なため、これは一種の前提条件です）。また、多くの場合、アルゴリズムはwrite（）などの一般的なコマンドに完全に定義せずに依存しています。

アルゴリズムがハードウェアアーキテクチャからそれほど抽象的ではないもう1つの理由は、いくつかの制約を満たす必要がある場合です。

組み込みシステムで作業している場合、おそらくワークステーションにある同じ量のリソースに頼ることはできません。最も抑制されたリソースの1つはおそらくメモリです。ただし、ほとんどのアルゴリズムは、メモリの複雑さ（データの処理に必要なメモリの量）ではなく、時間の複雑さ（CPUでの実行速度）を最適化する傾向があります。これらのシステムでは、メモリに最適化されていないアルゴリズムが失敗するか、実行速度が大幅に低下するメモリ最適化アルゴリズムが考案されました。実際、組み込みシステムはメモリ効率の良いアルゴリズムの唯一のターゲットではありません。たとえば、CPUキャッシュを効率的に使用するために処理を適応させるキャッシュ忘却型アルゴリズムがあります。別の例：ビッグデータ用の機械学習アルゴリズムの一部は、任意のコンピューターなどで使用可能なメモリよりもはるかに大きい膨大な量のデータを処理するためのインクリメンタル学習またはアウトオブコアコンピューティングなど

また、コンピューターの特定の部分を最適化するのではなく、ハードウェアアーキテクチャに依存する標準を最適化するアルゴリズムもあります。たとえば、精度が必要な数値データはfloatまたはdouble内に格納されますが、これらはハードウェアの制限により本質的に制限されています。問題は、複雑な計算が丸めにつながる可能性があり、丸められた数値に対してより多くの計算を行うと、より多くのドリフトが発生することです。これは壊滅的な干渉と呼ばれます。いくつかのアプリケーションは、最悪の複雑さを犠牲にしても、非常に高い精度を必要とします。このタイプのアプリケーションでは、計算を最適化して壊滅的な干渉を削減または除去するアルゴリズムが作成されました。

したがって、アルゴリズムの設計は、抽象化と制約の間のトレードオフにもなり得ます。

最終的に、アルゴリズムは、ターゲットと同じくらい抽象的であり、前提条件（アーキテクチャ）のニーズと同じであると言えます。アルゴリズムのターゲットがより具体的であればあるほど、おそらくハードウェアアーキテクチャに依存します。

興味のある関連キーワード：

• 参照の局所性
• ループ最適化
• ループネストの最適化
• スケーラブルな局所性

一般的なアルゴリズムと数学アルゴリズムまたは計算アルゴリズムを混同しないでください。計算アルゴリズムを意味する場合、はい、それらはマシンアーキテクチャから独立しています。

ウィキペディアのアルゴリズムの定義：

数学とコンピューターサイエンスでは、アルゴリズムとは、実行される一連の自己完結型の操作です。計算、データ処理、および自動推論を実行するアルゴリズムが存在します。

この定義は、いくつかの閉じた計算またはデータ処理タスクを参照するために使用されます。つまり、Turing Machineで抽象的に実行できる計算。ただし、最近では、計算中に外部世界との入出力通信を含む対話型計算という数学の概念があります。

一般的な定義では、アルゴリズムは単なるレシピ（一連の指示）です。使用できる命令セットまたは操作を知らないと、アルゴリズムを考えることはできないと思います。数学演算は計算に関するもので、「オーブンを熱する」という名前のステップを含むアルゴリズムは数学的なアルゴリズムではありませんが、シェフに実行方法を知っているため、シェフに渡すことができます。

次に、X、Y、Zを実行できるマシンを作成します。これらはそれぞれ、アルゴリズムとして命令として使用できます。しかし、それらがすべて閉じた計算（実際、非対話型の決定的なデジタル小ステップ計算）である場合、マシンがTuring Machineと同等であることを証明できます。しかし、他のタイプの計算（値または対話型計算（実際には別のタイプの計算であるかどうかはわかりませんが））または非計算タスクを対象とする場合、それらを実行できるマシンを考えることができます。

この質問と回答は、アルゴリズムについてより広い視野を得るためにも興味深いものです。

一般に、アルゴリズムは「コスト」の測定値を最小限に抑えながら、特定の問題に合わせて設計されています。歴史的に、多くのアルゴリズムは、一般的な操作の相対コストが多くのアーキテクチャで比較的似ているという前提で設計されていたため、一部の典型的なマシンはあるアルゴリズムを別のアルゴリズムよりもよく実行し、ほとんどの典型的なマシンでは前のアルゴリズムが最悪の場合、後者よりわずかに劣っています。時間が経つにつれて、そのような仮定は以前ほどには成り立たなくなりました。

たとえば、プログラムがメモリからものを読み取る必要がある回数は、読み取るものの場所よりも重要であると考えられていました。記憶の中で互いに近くにあるものを読むことは、遠く離れているが、とんでもないことではないものを読むよりもいくぶん安価でした。ただし、メインCPUの速度がメモリ速度をはるかに超える速度で増加するにつれて、アクセスシーケンスの重要性が大幅に向上しています。前のプログラムのメモリフェッチの95％がL1キャッシュヒットを生成し、後者のプログラムのメモリフェッチの大部分がキャッシュミスを生成する場合、1つのプログラムが別のプログラムの10倍の命令を実行し、さらに高速に実行することが可能です。

さらに、特定の種類の同時実行関連アルゴリズムは、あるプロセッサコアによってメモリに書き込まれたデータが他のコアによって「見える」時期についてさまざまな仮定を行います。多くのプロセッサには、さまざまなコストでメモリを読み書きできるさまざまな方法があり、可視性に関する保証があります。一部のアルゴリズムは、可視性の要件を「無料で」満たすことができるアーキテクチャで非常にうまく機能しますが、それらの保証に必要な指示が高価な他のアルゴリズムでは不十分です。実際、一部のアーキテクチャでは、特定の同時実行関連アルゴリズムは、実行を単一の時分割CPUコアに制限することによってのみ動作することが保証されます（もちろん、同時実行アルゴリズムを使用するポイントを無効にします）。

多くの答えは、アーキテクチャからの抽象的または直接的なリテラル関係のいずれかでアルゴリズムを定義できるという事実を欠いています。アルゴリズムは明確である必要がありますが、ある程度具体的である余地がまだあります。

文字列をすべて大文字に変換するアルゴリズムは、アーキテクチャに依存しない擬似コードで簡単に記述できます。しかし同時に、特にx86アーキテクチャで文字列をすべて大文字に変換するためのアルゴリズムを記述することを妨げるものは何もありません。必要なのは、x86アセンブリの宿題です。（まだこれを擬似コードで行うことができます-そのアーキテクチャに関連する擬似コードだけです！）問題が特にx86アーキテクチャでこれを行うためのものであるという事実だけでは、それを解決するアルゴリズムがもうないというわけではありません。

それは解決するためにアルゴリズムが定義されている問題に依存します。解決する問題がアーキテクチャに依存しない場合は、アルゴリズムはアーキテクチャに依存しません（そして、アルゴリズムの記述や組み立ての方法で元に戻さないと仮定します）。問題は、理論上の黒板の問題か、非常に具体的なアーキテクチャの問題のいずれかです。後者の場合、アルゴリズムはそのアーキテクチャでの作業に限定されます。

アルゴリズムは一連のステップです。それらは何を実行しているか（または実行していないか）に依存しません。

しかし、時間の複雑なアルゴリズムのは、することができ、それを実行しているかに依存します。そのため、アルゴリズムの詳細な分析には、ランダムアクセスマシンなどの「計算モデル」が必要です。
メモリにランダムにアクセスできるかどうかは、アルゴリズムの実行にかかる時間に確実に影響します。実際、ほとんどのアーキテクチャはこの条件を満たさないのに対し、ほとんどのアルゴリズムはこれに該当すると想定しています。

それらは問題の異なるコンテキストで異なります。アルゴリズムは、問題を解決するための手順の集まりです。この問題の背景は理論的には何でもかまいません。したがって、問題を解決するアルゴリズムは、文字通り、想像できる宇宙上のあらゆるものに依存する可能性があります。例を挙げて説明します。あなたにタスクが与えられたとしましょう。

マルチコアが利用可能な場合、複数のコアに負荷を分散するアルゴリズムを構築します。

アルゴリズムがアーキテクチャに依存するかどうかを想像できますか？もちろんそうです。