問題タブ [pybind11]

そのため、C/C++ プログラムとやり取りするためにいくつかの Python コードを作成する必要があるプロジェクトを行っていますが、どのツールを使用するか決めていません。直感的に、 pybind11とBoost.Pythonのどちらかを選択したいと思います。プログラマー: 両者の長所と短所は何ですか? どちらを使用するかをどのように決定しますか?

私のプロジェクトでは、pybind11を使用して C++ コードを Python にバインドします。最近、私は非常に大きなデータ セット (70 GB 以上) を処理する必要があり、データを 1 つのデータからstd::deque複数std::dequeのデータ セットに分割する必要が生じました。私のデータセットは非常に大きいため、分割によるメモリ オーバーヘッドはそれほど大きくないと予想されます。したがって、私は 1 ポップ - 1 プッシュ戦略を採用しました。これにより、一般的に、私の要件が確実に満たされるはずです。

それはすべて理論上です。実際には、私のプロセスは殺されました。そのため、過去2日間苦労し、最終的に問題を示す最小限の例を思いつきました。

一般に、最小限の例ではdeque(~11GB) に大量のデータを作成し、それを Python に返し、再度 を呼び出しC++て要素を移動します。そのような単純な。移動部分はエグゼキュータで行います。

興味深いことに、エグゼキュータを使用しない場合、メモリ使用量は期待どおりであり、ulimit による仮想メモリの制限が課されている場合でも、プログラムはこれらの制限を実際に尊重し、クラッシュしません。

test.py

test.cpp

test/__init__.py

コンパイル:

所見:

• 移動部分がエグゼキュータによって行われないため、 を呼び出すだけで、すべてが期待どおりに機能し、moved_numbers = _test.move(numbers)htop によって示されるメモリ使用量は約のままです。11Gb
• エグゼキュータで部分の移動を行うと、プログラムが 2 倍のメモリを消費してクラッシュします。

• 仮想メモリの制限 (~15Gb) が導入されると、すべてが正常に機能します。これはおそらく最も興味深い部分です。

  ulimit -Sv 15000000 && python3.5 test.py>> Done!.

• 制限を増やすと、プログラムがクラッシュします (150Gb > 私の RAM)。

  ulimit -Sv 150000000 && python3.5 test.py>>[1] 2573 killed python3.5 test.py

• deque メソッドの使用はshrink_to_fit役に立ちません (また、そうすべきではありません)

使用ソフトウェア

ノート

この例は、単に問題を示すために作成されたものであることに注意してください。問題が発生するためには 、asyncioとの使用が必要です。pybind

何が起こっているのかについてのアイデアは大歓迎です。