プログラミングのどの領域で、アルゴリズムの実行時間は実際に重要な問題ですか？

プロセッサの速度と利用可能なメモリの量のために、アルゴリズムの効率と実行時間は実際には大きな関心事ではないと人々が言うのを時々聞きます。

しかし、そのような考慮事項が最も重要なままである領域がまだあると思います。頭に浮かぶのは、数千のトランザクションを数秒で実行する必要があるアルゴリズム取引と、メモリと電力が不足していることが多い組み込みシステムのプログラミングです。これらの例については正しいですか？また、他のどの領域も例になりますか？

速度は常に求められています。私はあなたが正しいと思います。以下に、きちんとしたアルゴリズムが求められている例をいくつか示します。

1. 暗号化

2. 大規模データベースの検索

3. ソートとマージ

4. ワイルドカードを含むテキスト検索（インデックスなし）

5. 集中的な計算での数学の問題

6. シミュレーション

7. データマイニングアプリケーション

8. アニメーション

9. AI

10. コンピュータビジョン

より強力なハードウェアでより長時間実行されるアルゴリズムを単純にパンチスルーできるようになったため、アルゴリズムの実行時間が大した問題にならない場合があります。しかし、間違いなくスピードアップが不可欠な場所がいくつかあります。

一般的に、巨大なデータセットを使用するものはすべて問題になります。nでスケーリングが不十分なものがあり、それから非常に大きな数になると、問題が発生します。Computational Scienceベータサイトにアクセスして少し調べてみると、より優れた、より高速なアルゴリズムを必要とする多くの問題を見つけることができると思います。私が遭遇したいくつかの分野：

• 特に複雑な統計分析。非効率的なアルゴリズムと大規模なデータセットの組み合わせは、大幅なスローダウンを意味します。いくつかの研究では、これは重要ではないかもしれませんが、速いターンアラウンドで何かをしようとしている場合はどうでしょうか？化学/核/生物学的脅威監視システムを実行している場合、「1か月後にサーバーから外れます」はおそらく悪いことです。
• 大規模なデータセットでのデータマイニング。
• 多くの変数を含むシミュレーション。

一般的に言って、科学計算は一般に、プログラムが複雑であるため、アルゴリズムが遅い場合（非常に大きなnに悩まされている場合）深刻な速度低下の機会を生成する領域のようです。そして、あなたが言ったように、金融アプリケーションがあります。取引でお金を稼ぐか失うかをミリ秒単位で決定できる場合、「何か十分な」アルゴリズムは、実行できるより良い方法があればそれを削減しません。

プロセッサの速度と利用可能なメモリの量のために、アルゴリズムの効率と実行時間は実際には大きな関心事ではないと人々が言うのを時々聞きます。

塩の粒でそれを取る。基本的に、計算能力が高いということは、nが大幅に遅くなる前にnが大きくなる可能性があることを意味します。ほとんどの日常的な問題では、このnは十分に大きいため、気にする必要はありません。ただし、アルゴリズムの複雑さをまだ知っている必要があります。

より多くの利用可能なリソースがある場合、後でより多くのデータを処理する必要がある場合があります。今日、100,000行の10MBログファイルを分析する必要があります。1年で、1,000,000,000行の100GBログファイルが作成される場合があります。データの量がリソースの能力よりも速く増加すると、後で問題が発生します。

使用可能なリソースが増えると、より多くのレイヤーが互いに積み重ねられます。OS、OSフレームワーク、サードパーティフレームワーク、言語インタープリター、そして最後に独自のツール。すべての異なるレイヤーのすべての不必要な非効率性は増大します。明日、あなたのツールは、より多くの機能を備えた新しいOSで実行される可能性があります。

したがって、あなたの質問に答えるには、さらに多くのデータをクランチする必要がある場所（他の回答で十分な例が示されている）、および最終ツールを提供せず、他のツールの別の抽象化レイヤーを提供する場所に注意する必要があります。

数年前、私はnラックに配置された試験管を2つの異なるパーティションに分類するアルゴリズムを書かなければなりませんでした。 「選択された」チューブと「選択されていない」チューブの両方があります（圧縮などの追加要件がありました）。各ラックには、最大100本のチューブが含まれていました。

このアルゴリズムは、製薬研究所のチューブ選別ロボットを駆動するために使用されることになっていました。

元の仕様が私に与えられたとき、私は使いやすさはそれほど痛くないと思ったので、約2000分のチューブをソートするために1分の計算時間の領域に割り当てられました。ロボット自体が遅いので、すべての可能な組み合わせの上で動きの数が最小であるという要件がありました。

暗黙の仮定は、複雑さは管の数に対して指数関数的であるということでした。しかし、アルゴリズム設計の作業中に、チューブの最適な分割を実行するラックの数が速いO(n)アルゴリズムがあることを発見しましたn。その結果、アルゴリズムの並べ替え時間が瞬時に行われるため、ユーザーが並べ替え操作を構成すると、並べ替えの表示がリアルタイムで更新されます。

私にとって、変更のたびに1分間座っているユーザーとすぐに反応するGUIの違いは、機能的に十分なソフトウェアと使いやすいソフトウェアの違いでした。

その他の分野には、多くの種類のリアルタイム信号処理、フィードバック制御システム、石油探査デコンボリューション、ビデオ圧縮、レイトレーシングおよび映画フレームレンダリング、仮想現実システム、高フレームレートが大きな競争上の優位性をもたらすゲーム、およびスマートフォンなどが含まれます。多数のCPUサイクルがユーザーのバッテリー寿命を速く消費するモバイルデバイスアプリ。

これまでに構築されたトップ500のスーパーコンピューターには、それを最大限に活用し、何らかの問題を解決するためにさらなる計算能力または優れたアルゴリズムを希望する研究者の待機リストがある可能性があるため、この質問が尋ねられることは非常に驚いています（がんを解読するためにタンパク質を折り畳むなど）、退職する前に。

私が思うになどの検索エンジングーグルとBingのは、複雑なアルゴリズムが使用されている最大の地域の一つであり、彼らは、ユーザーに多くの有用性をもたらす関連で（ランキングページ）結果を高速化において重要な役割を果たしています。

効率的なアルゴリズムを使用しているため、今日ではアルゴリズムの効率は大きな関心事ではありません。O（n！）アルゴリズムを使用した場合、あらゆる種類のハードウェアで遅くなります。

膨大なデータ量が増加するにつれて、アルゴリズムの複雑さがますます重要になっています。幸いなことに、一般的なプログラミング問題（主に検索と並べ替え）に対する効率的な汎用ソリューションは、ほとんどすべての最新のプログラミング言語の標準ライブラリに含まれているため、通常、プログラマーはこれらのことをあまり心配する必要はありません。欠点は、多くのプログラマーが内部で何が起こっているのか、使用するアルゴリズムの特性が何なのかをまったく知らないことです。

多くのアプリケーションが適切にストレステストされていないため、これは特に問題になります。人々は小さなテストデータセットでうまく機能するコードを書きますが、数千倍のデータに直面すると、コードは停止します。データセットが大きくなると、10個のレコードでうまく機能するものがすぐに爆発します。実際の例：どのカテゴリにもリンクされていないアイテムを一掃することになっているコードは、3レベルのネストされたループ（O（n ^ 3））を使用しました。テストデータベースに記録が10個しかないため、これは1000回のチェックを意味し、完全に実行可能であり、顕著な遅延は発生しません。ただし、実稼働データベースは約1000行ですぐにいっぱいになり、突然コードは毎回10億のチェックを行います。

だから、いいえ、あらゆる種類のきちんとしたアルゴリズムを実装することの詳細を知る必要はなく、独自のアルゴリズムを発明する必要はありませんが、一般的なアルゴリズムの基本的な知識が必要です強みと弱みは、それらを使用するときと使用しないときであり、アルゴリズムの複雑さの影響の可能性に注意する必要があります。そのため、許容できる複雑さのレベルを決定できます。

どのアプリケーションドメインがランタイムに依存するかは問題ではありません。どのプログラムでも、どこでも、最小限のパフォーマンスがあり、それを下回ると実質的に価値がありません。アルゴリズムの複雑さのポイントは、入力サイズの増加に応じてどのように変化するかです。つまり、速度が特に重要な領域は、現在の問題のサイズだけでなく、桁違いに拡張する必要があると予想される領域です。現在の問題のサイズ。フランスの県の市民の税務申請を処理する場合、タスクは大きくなる可能性がありますが、人口の規模または1つのレコードの処理の複雑さが10倍または100倍になることはほとんどありません。あなたは今、おそらく働き続けるでしょう。しかし、あなたは、インターネットボリュームでオフになります何かを作成しようとすると、アルゴリズムの複雑さがキーである：より直線的に依存またはログ線形入力サイズに何をしますだけではないことができる非常に高速ではるかに高価になり、最終的にプロセッサの速度成長に追いつく。

私の分野（VFX、パストレーシング、コンピューターアニメーション、粒子シミュレーション、流体力学、画像処理などをカバー）では、アルゴリズムの複雑さが基本です。特に数百万の頂点、ポリゴン、ボクセル、パーティクル、テクセルに到達する入力で、線形時間よりも悪い状態で動作するものが妥当な時間で完了することを期待することはできません。リアルタイムのインタラクティブなフィードバック。

そうは言っても、同僚の間での議論では、アルゴリズムの複雑さはそれほど重視されていません。おそらくそれはやや当たり前で、むしろ「初歩的」だと思われるためです。一般に、パストレーサーを作成する場合、対数時間以上で動作すること、およびバウンディングボリューム階層などのデータ構造は読者にとって使いやすく、比較的簡単に実装できると想定されています。マルチスレッドとSIMDはアルゴリズムよりも重要であると言い続けた熟練した同僚もいましたが、バブルの並べ替えの並列化から多くを得ることができるという意味で彼が言ったとは思いません。彼は賢明なアルゴリズムを適用すると当然だと思っていたので、

最近の多くの焦点は、これらの使い慣れたアルゴリズムの多くを採用し、CPUキャッシュ、SIMDレジスタと命令、GPU、マルチコアなどのハードウェアの基本的な特性をより活用することにあります。たとえば、Intelは、おなじみの古いBVHを使用して「レイパケット」の概念を考案し、基本的に複数のコヒーレントレイを再帰的なツリートラバーサルでテストする新しい方法を考案しました「SIMD命令とレジスタを使用して、レイ/ AABBおよびレイ/三角形の交差点でこれらのレイを同時にテストできるという事実によって構成されていることを除いて、複雑さとオーバーヘッドがあります）。

同様のことはcatmull-clarkサブディビジョンのようなもので、コンピューターグラフィックスでは非常に初歩的なものです。しかし今日、競争力があり、熱く、非常に効率的なのは、Gregory Patchesを使用したCCサブディビジョンに近いGPU実装です。CharlesLoopによって普及し、後にPixarで採用されました。より単純なCPU実装は、アルゴリズムの複雑さの点で必ずしも置き換えられたわけではなく、GPUで適切に動作するものに置き換えられたため、かなり時代遅れです。

そして、これは通常、最近のハードウェアの基本的な特性に比較的依存しない方法で最良のアルゴリズムを思い付かないという課題の多くです。空間インデックスとは対照的に、階層セグメンテーションアプローチを使用して、90年代のキャラクターやその他のソフトボディをアニメーション化するための衝突検出を大幅に高速化する新しい加速構造を思いつくことで、実際に業界に足を踏み入れました。求人はありますが、このような印象的なCPUキャッシュと複数のコアとプログラム可能なGPUが存在するずっと前に公開したので、最近ではそれほど印象的ではありません。最近では、大幅な変更の結果として、まったく異なるアプローチを使用しています基礎となるハードウェア。

アルゴリズムが通常O（n）で実行される問題に遭遇しましたが、まれで非常にまれな状況でO（n ^ 3）時間を必要とします-「まれな」状況は、 1つのオペレーティングシステムが別のオペレーティングシステムではありません。

誰も問題に遭遇しませんでした。次に、ある顧客が戦略を使用して、O（n ^ 3）ケースに体系的に実行されるファイルに名前を付け、そこに数100個のファイルがあると、システムは仮想的に停止しました。その結果、アルゴリズムを変更する必要がありました。

まだ言及されていない3つ：

1）多くのリアルタイム戦略ゲーム。位置を共有できないユニットを持っているものを見てください。ユニットの大規模なグループが制限された地形を移動すると、経路探索がどうなるかを確認します。まだ十分なCPUパワーが利用できないため、これに関する何らかの大きな問題のないゲームにはまだ遭遇していません。

2）多くの最適化の問題。（編集：この回答を書いてから、私はヒットしました。私の目的は、すべてのノードが接続パスの最小重みで接続されたままになるように冗長パスを整理することでした。そのルーチンに、それは2 ^ nであることに気づいた。今ではn ^ 2であるが、それは時々わずかに最適でない結果を生成することがある。

3）大量のデータをリアルタイムで操作する必要があるもの。DVDを考えてみましょう。通常、4.7GBで2時間のビデオを取得できます。同じ解像度の一般的なビデオファイルを考えてみましょう。これらの2時間のビデオは、通常1 GB未満です。これは、DVDの仕様が定められていたため、最新のフォーマットを十分に速くデコードできるリーズナブルな価格のDVDプレーヤーを作成できなかったためです。

まあ、通常はスーパーコンピューター（最大のマシンのリスト）で実行されるアプリケーションはすべて適格です。これらは多様ですが、それらの大きなサブクラスは物理シミュレーションです：

• 物理シミュレーション：
  • 天気予報
  • 気候シミュレーション
  • 爆発する星などのシミュレーション
  • 爆発する核のシミュレーション
  • 車/飛行機/電車などの空力シミュレーション
  • ...
• 電波望遠鏡のデータから画像を計算する
• 生物学的応用：
  • DNA配列を含むもの（私はそれらにはあまり興味がありません）
  • タンパク質の折りたたみのような生化学的なもの
  • 神経細胞がどのように連携して情報を処理するかのシミュレーション
  • 生態系のような他の複雑な相互作用のシミュレーション
  • ...
• ...

これらは私の頭のトピックのトップに過ぎませんが、異なるスーパーコンピューターのリストを読むだけで、これらのすべてがこれらの巨大なマシンなしでは不可能な何らかの種類の計算を可能にするために構築されていることがわかります。

そして、これらのマシンが実際に必要であることがわかったら、これらのアプリケーションを10％高速化するだけで、どれだけのコストを節約できるかを実感してください。これらのコードを最適化すると、これらのマシンから取得できる結果の量が直接増加します。