私は通信、解析、データ処理機能を Win32 から Linux に移植するベンチャーに携わっており、両方がサポートされます。問題のドメインは、スループットとパフォーマンスに非常に敏感です。
私は、boost と ACE のパフォーマンス特性についてほとんど経験がありません。具体的には、スレッド化に最適なパフォーマンスを提供するライブラリを理解したいと考えています。
両者の相対的なパフォーマンスに関するデータ (文書化されたもの、口コミ、またはおそらくいくつかのリンク) を提供できる人はいますか?
編集
皆さんありがとう。最初の考えを確認しました - システムレベルのクロスプラットフォームのものにはブーストを選択する可能性が最も高いです.
どちらのライブラリも、ネイティブ OS のスレッド機能を使用する場合と比較して、実際にはオーバーヘッドがありません。どの API がよりクリーンであるかを確認する必要があります。私の意見では、ブースト スレッド API は非常に使いやすいです。
ACE はより「古典的な OO」になる傾向がありますが、boost は C++ 標準ライブラリの設計から引き出される傾向があります。たとえば、ACE でスレッドを起動するには、ACE_Task から派生した新しいクラスを作成し、スレッドの実行時に呼び出される仮想 svc() 関数をオーバーライドする必要があります。ブーストでは、スレッドを作成し、必要な関数を実行します。これにより、侵襲性が大幅に低下します。
自分に有利に働き、ACEを避けてください。あなたが私に尋ねれば、それは決して書かれるべきではなかった恐ろしい、恐ろしいライブラリです。私は3年間働いてきました（またはむしろそれを使って作業しなければなりませんでした）、それは古風なC ++を使用し、完全に脳死した設計上の決定に基づいて構築された、設計、文書化、実装が不十分なジャンクだと言います...ACEを呼び出します「Cwithclasses」は実際にそれを支持しています。その構成のいくつかの内部実装を調べると、絞扼反射を抑えるのに苦労することがよくあります。また、「不十分なドキュメント」の側面を十分に強調することはできません。通常、関数を文書化するというACEの概念は、関数の署名を単に印刷することで構成されます。その引数の意味、その戻り値、およびその一般的な動作については、あなたは reは通常、自分でそれを理解するために残されています。関数がスローする可能性のある例外、成功を示す戻り値、関数に必要な処理を実行させるために渡さなければならない引数、または関数/クラスがスレッドセーフかどうかを推測する必要があることにうんざりしています。か否か。
一方、Boostは使いやすく、最新のC ++であり、非常によく文書化されており、機能します。ブーストはACEでダウンする方法です！
スレッドおよび同期オブジェクトの OS 抽象化レイヤーのオーバーヘッドについて心配する必要はありません。スレッド化のオーバーヘッドは文字通りまったく問題になりません (スレッドの作成にのみ適用されるため、pimpl 化されたポインター間接化のオーバーヘッドと比較して、スレッドの作成はすでに非常に遅いため)。ミューテックス操作が速度を低下させていることがわかった場合は、アトミック操作を検討するか、競合を避けるためにデータ アクセス パターンを再配置することをお勧めします。
ブーストと ACE に関しては、「新しいスタイル」と「古いスタイル」のプログラミングの問題です。Boost には、ヘッダーのみのテンプレート ベースの悪ふざけがたくさんあります (理解できれば、操作するのが美しいです)。一方、「C with classes」スタイルの C++ に慣れている場合、ACE はより自然に感じるでしょう。それは主にチームの個人的な好みの問題だと思います。
私は数多くの負荷の高い運用サーバーに ACE を使用してきました。それは決して私を失敗させませんでした。それは堅実で、何年もの間仕事をしています。BOOST の ASIO ネットワーク フレームワークを学習しようとしましたが、コツがつかめませんでした。BOOST はより「最新の」C++ ですが、重要なタスクに使用することも困難です。また、「最新の」C++ の経験と STL の深い知識がなければ、正しく使用することは困難です。
ACE は一種のオールドスクール C++ ですが、boost がまだ提供していない多くのスレッド指向の機能を備えています。
現時点では、両方を使用しない理由はありません (ただし、目的は異なります)。タスク間にメッセージ キューを実装する簡単な手段がブーストによって提供されたら、私は ACE を放棄することを検討するかもしれません。
使いやすさに関しては、Boost は ACE よりもはるかに優れています。boost-asio にはより透過的な API があり、その抽象化はよりシンプルで、アプリケーションにビルディング ブロックを簡単に提供できます。コンパイル時のポリモーフィズムは、不正なコードを警告/防止するためにブーストで慎重に使用されます。一方、ACE のテンプレートの使用は一般化に限定されており、違法な操作を禁止するほどユーザー中心になっていることはほとんどありません。ACE を使用すると、実行時に問題を発見する可能性が高くなります。
私が考えることができる簡単な例は ACE_Reactor です - かなりスケーラブルで分離されたインターフェースですが、作成された場所とは異なるスレッドでイベントループを実行している場合は、「独自の」関数を呼び出すことを忘れないでください。初めてこれを理解するのに何時間も費やしましたが、何日も簡単に費やすことができたでしょう. 皮肉なことに、そのオブジェクト モデルは、非表示にするよりも多くの詳細を表示します。学習には適していますが、抽象化には適していません。
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
私はACEを「クラス付きのC」とは呼びません。ACEは直感的ではありませんが、時間をかけて意図したとおりにフレームワークを使用すれば、後悔することはありません。
私の知る限り、Boostのドキュメントを読んだ後、ACEのフレームワークとBoostのコンテナクラスを使用したいと思います。
スレッディングは実際には、boost と ACE が提供するもののほんの一部にすぎず、2 つを全体的に比較することはできません。ACE はかなり重いフレームワークであるため、boost の方が使いやすいことに同意します。
ACEを使用し、協力してブーストします。ACEはOOデザインパターンに基づいたより優れた通信APIを備えていますが、Boostは「最新のC ++」デザインに似ており、たとえばコンテナーでうまく機能します。
私たちは、ACE を使用することで、Windows と UNIX の間に存在する TCP ソケットと select 呼び出しのプラットフォームの違いを隠すことができると信じて、使用を開始しました。結局のところ、そうではありません。Ace の選択であるリアクター パターンでは、Windows でソケットと stdin を混在させることはできません。また、ソケットの書き込み可能性通知に関するプラットフォーム間のセマンティックの違いは、ACE レベルでも存在します。
これに気付いたときには、すでに ACE のスレッドとプロセス機能を使用していたので (後者は、私たちが望んでいたほどプラットフォームの違いを隠すことはありません)、コードは巨大なライブラリに結び付けられています。コードの 64 ビット MinGW への移植を妨げます!
私たちのコードで最後に使用された ACE が最終的に別のものに置き換えられる日が待ちきれません。
私は長年 ACE を使用してきました (8) が、次のプロジェクトでブーストの使用について調査を開始したところです。より大きなツールバッグ（正規表現など）があり、その一部がC++標準に吸収されているため、長期的なメンテナンスが容易になるため、ブーストを検討しています。とはいえ、ブーストにはある程度の調整が必要です。Greg は、スレッド サポートは任意の (C または静的) 関数を実行できるため侵襲性が低いと述べていますが、ACE_Task が提供する Java および C# スレッド クラスに類似したスレッド クラスの使用に慣れている場合は、ブーストで同じことを得るために少しフィネスを使用します。