Erlangは計算上高価な作業には適していません。プログラミングErlangの開始時に

Question

は、以下があります：

Erlangのプロジェクトのための最良の選択肢となりますか？それはあなたが何を探しているかによって異なります。 をビルドします。数値計算アプリケーション、グラフィックス 集中型システム、またはモバイル端末で実行されているクライアントソフトウェアを作成する場合は、申し訳ありませんが、 は間違った本を購入しました。

Erlangは計算上高価な作業には適していません。何がErlangをそれほど不適切なものにするか、あるいは私は誤解しましたか？

Answer 1

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

Erlangのは、それは集中的な問題を、計算するために来るときCおよびFortranなどの言語と一致しない理由として、私たちはコード生成とキャッシュへの優しさのようなものを考慮する必要があります...私はそれを試してみるよ：

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

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

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

Answer 2

ほとんどの場合、Cコードがかなり高速になることがあります。 Erlangはフォールトトレランス、分散コンピューティング、同時実行性に優れています。プログラマーはerlangや他の言語を書くのにも慣れ親しんでいる傾向がありますが、スピードが必要な場合はerlangポートからCやC++を使用してください。このコードは自分のerlangアプリケーションから使用できます。

Answer 3

Erlangは、大規模な産業用リアルタイムシステムをプログラミングするために設計された並列関数プログラミング言語です。具体的には、「数多くのアプリケーションやグラフィックスを必要とするシステム」を開発することはできませんが、この言語はリアルタイムのイベント処理に役立ちます。