erlang - Erlangが計算コストの高い作業に適さない理由は何ですか？

Question

プログラミングErlangの始めには、次のようなものがあります。

Erlangがあなたのプロジェクトに最適な理由は何ですか？それはあなたが構築しようとしているものに依存します。数の多いアプリケーション、グラフィックスを多用するシステム、または携帯電話で実行されるクライアントソフトウェアの作成を検討している場合は、申し訳ありませんが、間違った本を購入しました。

暗黙のメッセージは、Erlangは計算コストの高い作業には適していないということです。Erlangがこれほど不適切な理由は何ですか？それとも私が誤解したことがありますか？

Answer 1

Erlangは、I / Oバウンドのアプリケーション、つまり、CPUパイプラインを介して命令をプッシュできる速度ではなく、I/O操作のレイテンシとスループットを制限要因とする問題に適しています。Webサーバーとデータベースは、I / Oバウンドアプリケーションの良い例です。制限要因は、CPUではなくディスクとネットワークである可能性があります。従来の「計算量の多い」アプリケーションには、暗号化ツールや科学シミュレーションが含まれます。

計算量の多い問題に関して、ErlangがCやFortranなどの言語と一致しない理由については、コード生成やキャッシュの使いやすさなどを考慮する必要があります...試してみます。

• コード生成：通常、Erlangプログラムを起動すると、スレッドコードに基づく仮想マシンであるBEAMで実行されます。BEAMはほとんどの目的で十分に機能しますが、論理的な「命令」ごとのオーバーヘッドは、最新の最適化Cコンパイラによって生成される種類のコードよりもはるかに大きくなります。HiPEプロジェクトは、数年前にメインのOTPソースツリーに統合されたErlang用のネイティブコードコンパイラを提供します*。それは確かにErlangの数の処理能力を向上させますが、それでもうまく書かれたCまたはFortranプログラムと一致させるのは難しいでしょう。
• キャッシュの使いやすさ：メモリシステムは、最近のコンピュータの主要なボトルネックです。メインメモリからの読み取りには、数百プロセッササイクルかかる場合があります。この問題を解決するために、CPU設計者は、メモリの待ち時間を隠すためにいくつかのレベルのキャッシュを導入します。キャッシュは、コンピュータプログラムの2つの重要な特性である時間的および空間的特性を利用します局所性-つまり、最近参照されたメモリの領域（および近くの領域）が再び参照される可能性があります。CやFortranのような言語は、メモリが割り当てられる場所と方法を大幅に制御できるため、プログラマーはアルゴリズムを調整してキャッシュを適切に処理できます。同じことは、メモリ割り当てがプログラマーから隠され、仮想マシンによって自動的に処理されるErlangのような動的言語には一般的に当てはまりません。
• コードサイズ：空間的局所性に関する議論は、コードにも当てはまります。Erlangコードは、ネイティブ形式であろうとバイトコード形式であろうと、通常、対応するコンパイル済みCコードよりも大きくなります。これにより、命令キャッシュでミスが頻繁に発生します。

これは氷山の一角に過ぎず、私は決してErlangや言語実装の専門家ではないことを覚えておいてください。ただし、Erlangが科学シミュレーションを実行することはおそらくないという事実を怖がらせないでください。多くのアプリケーションにとって、それは絶対に素晴らしい言語です。

* HiPEは、Debianのerlang-base-hipeパッケージ、または./configure --enable-hipeソースtarballから入手できます。

Answer 2

ほとんどの場合、Cコードの方がかなり高速である可能性があります。Erlangは、フォールトトレランス、分散コンピューティング、および同時実行性に優れています。プログラマーはerlangや他の言語の記述にも同様に熟練している傾向がありますが、速度が必要な場合は、おそらくerlangポートからCまたはC ++を使用するため、このコードは独自のerlangアプリケーションから使用できます。

Answer 3

Erlangは、大規模な産業用リアルタイムシステムをプログラミングするために設計された並行関数型プログラミング言語です。「数を処理するアプリケーションまたはグラフィックを多用するシステム」の開発を特に妨げるものはありませんが、この言語はリアルタイムのイベント処理で優れています。