アルゴリズム（および一般的な効率）の重要性は低下していますか？

計算能力の購入は過去よりはるかに手頃であるため、アルゴリズムの知識と効率性はそれほど重要ではなくなりますか？無限ループを避けたいことは明らかです。そのため、すべてがうまくいくわけではありません。しかし、より良いハードウェアを持っているなら、どういうわけかもっと悪いソフトウェアを持っているでしょうか？

アルゴリズムの効率の重要性を示す「アルゴリズムの概要」の本の例をとても気に入っています。

$O(n^2) = c_1n^2$$O(n\log n) = c_2n \lg n$$c_1 < c_2$

ご質問にお答えするために、挿入ソートアルゴリズムを実行する高速コンピューター（A）とマージソートアルゴリズムを実行する低速コンピューター（B）の実行時間を評価します。

想定：

• $n=10^7$
• $10^{10}$
• $10^7$
• $c_1=2$$c_2=50$

したがって、これらの仮定では、

$$\frac{2 \cdot (10^7)^2 \text{ instructions}} {10^{10} \text{ instructions}/\text{second}} = 2 \cdot 10^4 \text{ seconds}$$ $10^7$

$$\frac{50 \cdot 10^7 \lg 10^7 \text{ instructions}} {10^{7} \text{ instructions}/\text{second}} \approx 1163 \text{ seconds}$$

コンピューターBの場合

したがって、1000倍遅いコンピューターは、17倍速く問題を解決できます。実際には、マージソートの利点はさらに重要であり、問​​題の規模が大きくなるにつれて大きくなります。この例があなたの質問に答えてくれることを願っています。

ただし、これはアルゴリズムの複雑さだけではありません。今日では、CPU周波数の高いマシンを使用するだけでは、大幅な高速化を実現することはほぼ不可能です。人々は、拡張性に優れたマルチコアシステムのアルゴリズムを設計する必要があります。コアの増加に伴い、（たとえばメモリアクセスを管理するための）オーバーヘッドも増加するため、これもトリッキーなタスクです。したがって、線形の高速化を実現することはほぼ不可能です。

要約すると、今日の効率的なアルゴリズムの設計は以前と同じように重要です。なぜなら、周波数の増加もコアの追加も、効率的なアルゴリズムによってもたらされるものに比べて高速化をもたらさないからです。

それどころか。ハードウェアが安くなっていると同時に、他のいくつかの開発が行われています。

まず、処理されるデータの量が指数関数的に増加しています。これにより、準線形時間アルゴリズムの研究、およびビッグデータの領域がもたらされました。たとえば、検索エンジンについて考えてみてください-大量のクエリを処理し、大量のデータを処理し、迅速に処理する必要があります。アルゴリズムはこれまで以上に重要です。

第二に、機械学習の分野は強く成長しており、アルゴリズムでいっぱいです（ただし、学士号で学ぶものとは異なります）。この分野は繁栄しており、真に新しいアルゴリズムが発明され、パフォーマンスが大幅に改善されています。

第三に、分散アルゴリズムはより重要になりました。これは、CPUの処理速度を向上させる上で障害になっているためです。最近では、並列化により計算能力が向上していますが、それには専用のアルゴリズムが必要です。

第4に、CPUの増大するパワーを相殺するために、現代のプログラミングパラダイムは、仮想マシンの手法を使用してセキュリティの抜け穴と戦います。これにより、これらのプログラムの速度がかなり低下します。難問に加えて、オペレーティングシステムは余計なCPU時間を余計なものに費やしており、実際のプログラムのCPU時間を削減しています。そのため、ハードウェアは高速ですが、効率的に使用されていません。

大量のデータを処理するには、要約し、効率的なアルゴリズムが必要です。人工知能の分野では、新しい種類のアルゴリズムが登場しています。分散アルゴリズムが注目されています。CPUの電力はさまざまな理由で効率が低下します（ただし、主にコンピューターの性能が向上しているため）。アルゴリズムはまだ死んでいません。

アルゴリズムの知識は、高速なアルゴリズムを記述する方法よりもはるかに多くのことです。

また、問題解決方法（分割統治法、動的計画法、貪欲法、縮約法、線形計画法など）を提供します。これは、新しい困難な問題に取り組む際に適用できます。通常、適切なアプローチをとることで、コードがよりシンプルになり、記述がはるかに高速になります。慎重にまとめられていないコードは、しばしば遅いだけでなく複雑でもあるため、Kevinの答えに反対する必要があります。David Parnasのこの引用が好きです。

開発者は、「大規模なシステムをすばやく構築する方法を知っている人」と言われることがよくあります。大規模なシステムを迅速に構築するのにトリックはありません。速く構築すればするほど、大きくなります！

（もちろん、アルゴリズムをソフトウェア設計手法と組み合わせて、適切なコードを記述する必要もあります。）

アルゴリズムの知識は、データ構造を使用してデータをより簡単かつ効率的に処理できるように、データを整理する方法も教えてくれます。

さらに、アプローチの効率を推定し、時間の複雑さ、スペースの複雑さ、コードの複雑さの点でいくつかの異なるアプローチ間のトレードオフを理解する方法を提供します。これらのトレードオフを知ることは、リソースの制約内で適切な決定を下すための鍵です。

ソフトウェアの効率の重要性について、ワースの法則を引用します。

ハードウェアが速くなるよりも、ソフトウェアが速く遅くなります。

ラリーペイジは最近、ソフトウェアは18か月ごとに2倍遅くなり、ムーアの法則を上回ると再表明しました。

はい、それらは幅広い業界では「比較的」重要ではありません。テキストエディタは「十分に高速」である可能性があり、それほど改善する必要はありません。ITの取り組みの大部分は、Javaで記述されたコンポーネントAがCで記述されたコンポーネントBと連携して、Cobol（または何か）で記述されたメッセージキューを介して正しく通信すること、または製品を市場に出すことなどに費やされます。

さらに、アーキテクチャは複雑になりました。サイクルごとに1つの命令があり、アセンブリで記述した単純な古い単純なプロセッサがある場合、最適化は「簡単」でした（命令の数を数えるだけで済みました）。現在、単純なプロセッサはありませんが、レジスタの名前変更と複数レベルのキャッシュを備えた、完全にパイプライン化されたスーパースカラーのアウトオブオーダープロセッサです。そして、アセンブリではなく、C / Java / etcで記述します。コードがコンパイル/ JITされた場所（通常、あなたまたは私がアセンブリで書いたよりも良いコードに）、またはPython / Ruby / ...でコードが解釈され、マシンからのいくつかの抽象化レベルによって分離されます。微小最適化は難しく、ほとんどのプログラマーは逆の効果を達成します。

いいえ、それらは研究においても「絶対」的にも重要です。大量のデータを処理するため、速度が重要な領域があります。このスケールでは、Pavelの例で示されているように複雑さが重要です。

ただし、さらにケースがあります-速度が重要な場合（HPC、組み込みデバイスなど）、アルゴリズムから「ダウン」することは依然として選択されたオプションです。コンパイラやソフトウェアの最適化を専門とする多くの大学グループがあります。たとえば、ループ順序の単純なスワップは、キャッシュを効率的に利用するという理由だけで千倍のスピードアップを得ることができますが、CPUとメモリのギャップは過去30年間で1000倍になります。また、コンピューターアーキテクチャもCSの一部です。したがって、計算速度の向上の多くは、実際には一般的なCS分野の一部です。

産業側では、1つのプログラムが数日、数か月、または数年実行できるため、HPCクラスターの速度が重要です。電気代を払う必要があるだけでなく、待つこともお金がかかります。2倍のハードウェアを投入できますが、7億ドルは大企業を除くすべての企業にとってポケットチェンジとは見なされません-そのような場合、プログラマーはより安価なオプションであり、プログラムを新しい言語に書き換えるのは単に「小さな」高速化を意味します-それらは考慮して下さい。

また、速度はより良いUXを意味するかもしれません。携帯電話のOSの多くのレビューでは、どれが「より迅速」であり、「トリック」によってそれを行うことができるが、それは確かに研究の領域です。また、データにすばやくアクセスし、必要なことをすばやく実行したい場合もあります。時にはそれはあなたがもっとできることを意味します-ゲームではすべてをするために0.017秒を持っており、より速くあなたが置くことができるキャンディーが多くなります。

興味深い議論です。そして、ここで見るべきことがいくつかあります。

1. 理論的なコンピューターサイエンス-これは進化する科学であり、時間が経つにつれて、問題を解決するための新しいより良い方法が見つかることを意味します。

2. より大きなコミュニティ/より大きなライブラリ-多くの作業が他の人々によって行われているため、彼らの作業を構築し、既に作成し、コーディングしたアルゴリズムを使用することができます。また、これらのライブラリは時間とともに更新され、より効率的なプログラム/アルゴリズムに自動的にアクセスできるようになります。

3. 開発-ここに問題があると思います。多くのプログラマーはコンピューター科学者ではないため、技術的/理論的な問題ではなくビジネス上の問題を解決するためのコードを記述し、たとえばバブルソートをクイックソートと同じくらい喜んで使用します。そして、ここでハードウェアの速度は、悪いプログラマーが悪いアルゴリズムと悪いコーディング慣行を使うことで逃げることを許しています。メモリ、CPU速度、ストレージスペースは、もは​​や大きな問題ではなく、数か月ごとに大きく、速く、安くなっています。新しい携帯電話を見てください。現在、1970年代/ 80年代のメインフレームコンピューター/サーバーよりも高度です。より多くのストレージ、より多くの処理能力、より高速なメモリ。

4. UIとデータ-ユーザーインターフェイス/ユーザーエクスペリエンスとデータは、開発のほとんどの分野で、非常に効率的なコードよりも重要であると考えられています。したがって、ユーザーが長く待たなければならない場合にのみ、速度が問題になります。ユーザーに見栄えを良くし、アプリケーションから良い反応を得たら、彼は幸せです。そして、ビジネスがすべてのデータが安全かつ安全に保存されていることを知っていれば、いつでもデータを取得して操作でき、必要なスペースを気にしません。

だから、効率的なプログラマーがもはや重要でも必要でもないということではなく、超効率的なプログラマーであることに対して人々に報酬を与える企業やユーザーはほとんどいないということです。効率的。しかし、少なくともまだ効率に焦点を当てた人々がそこにいます、そして、コミュニティ精神のために、時間の誰もがこれから利益を得ます。

現象の学際的で横断的な側面を強調する、この興味深く深い質問に関するいくつかの他の角度。ダイは、彼の答えでワースの法則を引用しています。

ハードウェアが速くなるよりも、ソフトウェアが速く遅くなります。

この考え方は、経済学で見られる現象と興味深い類似点があります。経済学はコンピュータサイエンスと多くの深いつながりがあることに注意してください。たとえば、「負荷分散」アルゴリズムによって、要求に応じて希少なリソース（スレッドなど）が割り当てられるスケジューリングなどです。別の例は、生産者と消費者のキューと呼ばれるものです。また、オークション。

また、例えば、同名の法律のリスト、ウィキペディア：

パーキンソンの法則 –「仕事は、その完了に利用できる時間を埋めるために拡大します。」C.ノースコートパーキンソン（1909〜1993）が造語しました。彼は、その結果として「支出は収入に応じて上昇します」とも言いました。コンピューターの場合：プログラムが展開され、使用可能なすべてのメモリーがいっぱいになります。

より効率的なワット蒸気エンジンがニューコメンの設計を置き換え始めた後、エネルギー使用量の増加で観察されたジェボンのパラドックスにもいくつかの強い類似性がありますが、エンジンの使用または増殖が増加しました：

経済学では、Jevonsパラドックス（/ ˈdʒɛvənz /;時にはJevons効果）は、リソースの使用効率を高める技術の進歩により、そのリソースの消費率が（減少ではなく）増加する傾向があるという命題です。

類推は、ハードウェアはリソースであり、ソフトウェアはリソースの消費のようなものです（別名、需要と供給）。したがって、ソフトウェアとハ​​ードウェア（およびそれぞれの進歩）は、ある意味で、相互に密接に共生したフィードバックループ内にある程度共存しています。この相互作用に影響する多くの複雑で相互に関連する要因があります。例えば：

• 共進化
• 進化レース
• ムーアの法則
• プログラミング言語/構造の急増
• 相対アルゴリズムとハードウェアの高速化

いいえ、主にスペースの複雑さを考慮しながら！通常のコンピューターのストレージ容量は指数関数的に増加しています。