ノンリニア最適化でのパフォーマンスが、ソルバエンジンとのインターフェイスの具体的な方法によってどのように影響を受けるかを理解することには、いくつかの困難があります。非線形ソルバーでは、ソルバー時間とNLP関数の評価にどのような影響がありますか？
私たちは、最初のバージョンでGAMSで書かれた最適化モデルを持っています。 IPOPT（共通のFOOS非線形ソルバエンジン）は、IPOPT（関数評価なし）で1.4 CPU秒、関数評価で0.2 CPU秒の各最適化の実行時間を返していました。
モデルをC++に変換して（モデルの最適化されていないコンポーネントをよりよく評価するために）、C++ API（ADOL-CとColPack for ADを使用）を使用してIPOPTをインターフェイスすると、実行時間は0.7秒IPOPTでは9.4秒、IPOPTの改善はIPOPTのソースでIPOPTをコンパイルすると、IPOPTのGAMSバージョンでは利用できないより優れた線形ソルバを使用できるようになったためです）。
ひどく最適化されたコードを使用しているC++を使用すると、GAMSよりも50倍も遅くなり、ソルバーの時間を短縮して部分的に補正しました。
PyomoとPyomo、Julia with JuMPのいずれかの言語でモデルを変換する可能性を評価しています。
しかし、各ステップでソルバーによって行われた関数評価が、実装された特定の言語にどのように依存するかを最初に理解したいと思います。
C++では、最適化モデルを作成する関数が各繰り返しで直接実行（評価）されるため、実装方法が重要です（特に、勾配とヘッセianは毎回再計算されます我々の実装では）。
PyomoとJuMPはどうですか？ PythonとJuliaで評価される各反復であるか、あるいはPyomoとJuMPは代わりに最初にモデルを（私が推測して）Cでレンダリングし、すべてのために勾配とヘッセ行列を計算します（評価しません）。毎回評価されるだろうか？ Pythonの場合は明らかに大きな違いがあります。
最初の質問：これらの2つの実装は同じですか？データは等しいか？モデルは？ランダムな種？あなたは同じ解決策を手に入れますか？私はこれらの質問のいくつかがノーで回答されていると確信しています。 2つの実装がまったく同じことをしていない場合は、特にヒューリスティックな動作がコアにあるハードな問題を解決する際に、評価するのが難しいです！これは実際にこれを分析するためにはるかに大きなベンチマークが必要であることを意味します。私は、機能の評価に多大な影響を与えるとは考えていないでしょう。しかし、それはちょうど推測です。 – sascha
（1）GAMSソルバIPOPTHは、MUMPS（2）を使用するIPOPTよりも性能がよくなるMA27を使用します。（2）GAMS関数およびグラディエント評価では、 （3）CONVERTソルバーにモデルを（醜い、スカラーの）Pyomoコードに翻訳させることで、pyomoを素早く試すことができます。 –