通常の「非ネイティブ」コンパイルと比較して.erl、オプションを使用して Erlang ソースをコンパイルする際の制限/制約は何ですか?+native
1498 次
1 に答える
11
BEAM エミュレータが提供するトレース、ブレークポイント、シングル ステップの機能は、ネイティブ コンパイル コードでは使用できません。また、同じモジュールの新しいバージョンをロードしたときに、ネイティブ コードが実際にはメモリからアンロードされないという制限もあります。(これは、モジュールをアップグレードし続けたり、モジュールを動的に生成およびコンパイルしたりする長時間稼働するシステムを使用している場合に問題になる可能性があります。)
さらに、ネイティブ コードとエミュレートされた BEAM コードの間をジャンプするときにわずかなオーバーヘッドが発生するため、速度が重要なタイトなループでこの種のモード スイッチを使用することは避ける必要があります。できれば、密接に関連するすべてのモジュールをネイティブにコンパイルし、可能であれば最も重要な標準ライブラリ モジュールもコンパイルします。
最後に、ネイティブ コンパイラは十分にテストされていますが、HiPE のコンパイラ バグの可能性は、BEAM エミュレータの C コードのバグの可能性よりも少し高くなります (ただし、GCC のバグの可能性よりは高くない可能性があります)。システムのセグメンテーション違反のリスクが高くなります。しかし、最近では非常にまれです。
要約すると、現時点でネイティブ コンパイルがおそらく推奨されない主な場所は、安定性、リモート デバッグ機能、メモリ使用量の削減が主な目的であるスタンドアロン製品 (顧客に提供するブラック ボックス サーバーなど) です。懸念と計算速度は通常ありません。
于 2010-02-06T10:07:53.550 に答える