我參與了一個合作項目，將把一些通信，解析，數據處理功能從Win32移植到Linux，並且都將得到支持。問題域對吞吐量和性能非常敏感。boost與ACE C++跨平臺性能比較？
我對boost和ACE的性能特點很少有經驗。具體而言，我們希望瞭解哪個庫爲線程提供了最佳性能。
任何人都可以提供一些數據記錄或口碑或者可能是一些鏈接關於兩者之間的相對錶現嗎？
編輯
謝謝大家。確認了我們最初的想法 - 我們很可能會選擇提升系統級跨平臺的東西。
與使用本地操作系統線程工具相比，兩個庫都不應該有任何開銷。你應該看看哪個API更清潔。在我看來，boost線程API非常易於使用。
ACE往往更「經典的面向對象」，而提升傾向於從C++標準庫的設計中吸取。例如，在ACE中啓動一個線程需要創建一個派生自ACE_Task的新類，並且重寫當線程運行時調用的虛函數svc（）。在boost中，你創建一個線程並運行你想要的任何函數，這是非常小的侵入性。
線程實際上只是boost和ACE提供的一小部分，而這兩者並沒有真正的可比性。我同意提升更容易使用，因爲ACE是一個非常沉重的框架。
不要擔心線程和同步對象上OS抽象層的開銷。線程開銷字面上根本沒有關係（因爲它只適用於線程創建，相比於pimpl-ized指針間接開銷，這已經非常慢）。如果您發現互斥體操作會讓您放慢速度，那麼最好查看原子操作或重新排列數據訪問模式以避免爭用。
關於升壓與ACE，這是一個「新風格」與「舊風格」編程的問題。 Boost有很多隻有標題的基於模板的惡作劇（如果你能欣賞的話，它們可以很好地工作）。另一方面，如果你習慣於C++的「C類」風格，ACE會感覺更自然。我相信這對你的團隊來說主要是個人品味的問題。
我不會把ACE叫做「C with class」。 ACE並不直觀，但如果你花時間按預期使用框架，你不會後悔。
從我所知道的，閱讀Boost的文檔後，我想使用ACE的框架和Boost的容器類。
幫你一個忙，避開ACE。這是一個可怕的，可怕的圖書館，如果你問我，它永遠不會寫出來。我已經工作了3年，但我告訴你這是一個設計不佳，文檔記錄不完整，使用陳舊C++並且建立在完全大腦死亡的設計決策之上的糟糕實現......調用ACE 「C與班」實際上是在幫忙。如果你看看它的一些構造的內部實現，你往往很難抑制你的反應。 另外，我不能強調「糟糕的文檔」方面。通常，ACE記錄函數的概念僅僅是打印函數的簽名。至於它的論點的含義，它的返回值和它的一般行爲，那麼你通常只能自己想出來。我厭倦了不得不猜測函數可能拋出哪些異常，哪個返回值表示成功，我必須傳遞哪些參數才能使該函數完成我所需要的操作，或者函數/類是否是線程安全的或不。
提高另一方面，使用簡單，現代C++，非常有據可查，它只是工作！升壓是一種去ACE的方式！
謝謝 - 即使在您激情澎湃的言論之前，我們仍將繼續努力 – Tim 2009-05-08 14:12:44
即使ACE是一種老派的C++，它仍然有許多線程導向的功能，目前尚未提供。
目前我沒有理由不使用兩者（但爲了不同的目的）。一旦boost提供了在任務之間實現消息隊列的簡單方法，我可能會考慮放棄ACE。
我一直在使用ACE多年（8），但我剛開始研究再次使用boost來完成我的下一個項目。我正在考慮增強，因爲它有一個更大的工具包（正則表達式等），並且它的一部分正在被吸收到C++標準中，所以長期維護應該更容易。這就是說，提升需要一些調整。雖然Greg提到線程支持的侵入性較小，因爲它可以運行任何（C或靜態）函數，但如果您習慣使用類似於ACE_Task提供的Java和C＃線程類的線程類，那麼您可以使用使用一點技巧來獲得同樣的提升。
我已經將ACE用於許多重型生產服務器。它從來沒有讓我失望。它堅如磐石，現在已經工作了很多年。試圖學習BOOST的ASIO網絡框架 - 無法理解它。雖然BOOST更「現代」C++，但它也很難用於非平凡的任務 - 並且沒有「現代」C++經驗和深厚的STL知識，難以正確使用
使用ACE並提升協作。 ACE具有更好的通信API，基於OO設計模式，而boost則像「現代C++」設計，並且與容器一起工作良好。
我們開始使用ACE認爲它會隱藏TCP套接字和選擇調用中windows和unix之間存在的平臺差異。事實證明，事實並非如此。 Ace的選擇反應堆模式不能在窗口上混合使用套接字和標準輸入，並且關於套接字可寫性通知的平臺之間的語義差異仍然存在於ACE級別。
當我們意識到這一點時，我們已經在使用ACE的線程和進程特性（後者再次不會將平臺差異隱藏到我們所希望的程度），以便我們的代碼現在綁定到巨大的庫，實際上阻止我們的代碼移植到64位MinGW！
我不能等待代碼中最後一個ACE用法最終被不同的東西代替的那一天。
說到易用性，提升比ACE好。 boost-asio具有更透明的API，其抽象更簡單，並且可以輕鬆地爲應用程序提供構建塊。編譯時多態性明智地用於提升以警告/防止非法代碼。另一方面，ACE對模板的使用僅限於泛化，幾乎不以用戶爲中心，不允許非法操作。 ACE更有可能在運行時發現問題。
我能想到的一個簡單例子就是ACE_Reactor - 一個可擴展且相互分離的接口 - 但如果您在與創建它的地方不同的線程中運行事件循環，則必須記得調用它的「自己」 。我花了好幾個小時才第一次弄清楚這件事情，而且很容易花上幾天的時間。具有諷刺意味的是，它的對象模型顯示出比隱藏更多的細節 - 對學習有好處，但對抽象不好。
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
尼斯比較。 – 2010-03-04 14:10:08
關於開始線程，這根本不是事實。 看一看： int ACE_Thread_Manager :: spawn（ACE_THR_FUNC func，void * arg = 0，...）; – alexkr 2010-10-04 11:28:45
沒錯，我還沒有使用過這個特殊的功能，但即使如此 - 它仍然需要像void * foo（void *）;（即pthreads-esque）這樣的函數簽名，所以你必須自己做參數綁定和包裝來返回一個void指針。 – 2010-10-05 23:47:22