boost vs ACE C ++跨平台性能比較？

Question

我參與了一項將從Win32遷移到Linux的一些通信，解析，數據處理功能的企業，並且都支持這兩種功能。 問題域對吞吐量和性能非常敏感。

我對boost和ACE的性能特征經驗很少。 具體來說，我們想要了解哪個庫為線程提供了最佳性能。

任何人都可以提供一些數據 - 記錄在案或口口相傳或者某些鏈接 - 關於兩者之間的相對表現嗎？

編輯

謝謝大家。 確認了我們最初的想法 - 我們最有可能選擇提升系統級跨平台的東西。

Answer 1

與使用本機OS線程設施相比，這兩個庫都不應該有任何開銷。 你應該看看哪個API更干凈。 在我看來，boost線程API更容易使用。

ACE傾向於更“經典的OO”，而提升往往來自C ++標准庫的設計。 例如，在ACE中啟動一個線程需要創建一個從ACE_Task派生的新類，並覆蓋在線程運行時調用的虛擬svc（）函數。 在boost中，您可以創建一個線程並運行您想要的任何功能，這種功能明顯較少。

Answer 2

幫自己一個忙，避開ACE。 如果你問我，這是一個可怕的，可怕的圖書館。 我已經工作了（或者更確切地說是HAD與它一起工作了3年）而且我告訴你它是一個設計糟糕，記錄不良，使用過時的C ++並且完全依賴於腦死亡的設計決策而實施得很糟糕的垃圾... “C with classes”實際上是在幫助它。 如果你研究一些構造的內部實現，你通常很難抑制你的嘔吐反射。 另外，我不能強調“糟糕的文檔”方面。 通常，ACE的記錄功能的概念包括簡單地打印功能的簽名。 至於它的論證的意義，它的回報價值及其一般行為，你通常只能自己解決這個問題。 我厭倦了不得不猜測函數可能會拋出哪些異常，哪個返回值表示成功，我必須傳遞哪些參數才能使函數執行我需要它做的事情或者函數/類是否是線程安全的或不。

另一方面，提升，使用簡單，現代C ++，非常有文檔記錄，它只是工作！ 使用ACE可以提升Boost！

Answer 3

不要擔心線程和同步對象上的OS抽象層的開銷。 字面上的線程開銷根本不重要（因為它只適用於線程創建，與異步指針間接開銷相比，這已經非常慢）。 如果您發現互斥操作正在減慢您的速度，那么您最好關注原子操作或重新安排數據訪問模式以避免爭用。

關於提升與ACE，這是“新風格”與“舊式”編程的問題。 Boost有很多僅基於模板的模板惡作劇（如果你能欣賞它，它們很漂亮）。 另一方面，如果你已經習慣了“C with classes”風格的C ++，ACE會感覺更自然。 我認為這主要取決於你的團隊的個人品味。

Answer 4

我已將ACE用於眾多重型生產服務器。 它永遠不會讓我失望。 它堅如磐石，現在已經做了很多年。 試圖學習BOOST的ASIO網絡框架 - 無法掌握它。 雖然BOOST是更“現代”的C ++，但它也更難用於非平凡的任務 - 沒有“現代”的C ++經驗和深入的STL知識，很難正確使用

Answer 5

即使ACE是一種舊式C ++，它仍然具有許多面向線程的功能，而這些功能尚未提供。

目前我認為沒有理由不同時使用兩者（但出於不同的目的）。 一旦boost提供了在任務之間實現消息隊列的簡單方法，我可以考慮放棄ACE。

Answer 6

說到易用性，提升比ACE更好。 boost-asio具有更透明的API，其抽象更簡單，可以輕松地為您的應用程序提供構建塊。 編譯時多態性在boost中明智地用於警告/防止非法代碼。 另一方面，ACE對模板的使用僅限於泛化，並且幾乎不以用戶為中心，不允許非法操作。 您更有可能在ACE運行時發現問題。

我能想到的一個簡單例子是ACE_Reactor--一個相當可擴展和解耦的接口 - 但如果你在一個不同於創建它的線程中運行它的事件循環，你必須記住調用它的“自己的”函數。 我花了幾個小時來第一次弄明白這一點，並且可以輕松度過幾天。 具有諷刺意味的是，它的對象模型顯示出比隱藏更多的細節 - 有利於學習，但對抽象有害。

https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA

Answer 7

線程實際上只是boost和ACE提供的一小部分，而且這兩者在整體上並不具有真正的可比性。 我同意boost更容易使用，因為ACE是一個相當繁重的框架。

Answer 8

我不會把ACE稱為“C with classes”。 ACE並不直觀，但如果你花時間按照預期使用框架，你就不會后悔。

據我所知，在閱讀Boost的文檔之后，我想要使用ACE的框架和Boost的容器類。

Answer 9

使用ACE並合作增強。 ACE具有更好的通信API，基於OO設計模式，而boost具有類似“現代C ++”設計，並且適用於容器。

Answer 10

我們開始使用ACE相信它會隱藏TCP套接字和select調用中windows和unix之間存在的平台差異。 事實證明，事實並非如此。 Ace的選擇，反應器模式，不能在Windows上混合套接字和stdin，並且有關套接字可寫性通知的平台之間的語義差異仍然存在於ACE級別。

當我們意識到這一點時，我們已經在使用ACE的線程和進程功能（后者再次沒有隱藏平台差異到我們想要的程度），所以我們的代碼現在綁定到一個巨大的庫，實際上阻止我們的代碼移植到64位MinGW！

我不能等待代碼中最后一次ACE使用最終被不同的東西取代的那一天。

Answer 11

我已經使用ACE多年了（8）但我剛剛開始調查我的下一個項目再次使用boost。 我正在考慮增強，因為它有一個更大的工具包（正則表達式等），它的一部分被吸收到C ++標准中，因此長期維護應該更容易。 也就是說，提升需要一些調整。 盡管Greg提到線程支持的侵入性較小，因為它可以運行任何（C或靜態）函數，但如果您習慣使用的線程類更類似於ACE_Task提供的Java和C＃線程類，那么使用一點技巧來獲得同樣的提升。