我参与了一项将从Win32迁移到Linux的一些通信,解析,数据处理功能的企业,并且都支持这两种功能.问题域对吞吐量和性能非常敏感.
我对boost和ACE的性能特征经验很少.具体来说,我们想要了解哪个库为线程提供了最佳性能.
任何人都可以提供一些数据 - 记录在案或口口相传或者某些链接 - 关于两者之间的相对表现吗？
编辑
谢谢大家.确认了我们最初的想法 - 我们最有可能选择提升系统级跨平台的东西.
与使用本机OS线程设施相比,这两个库都不应该有任何开销.你应该看看哪个API更干净.在我看来,boost线程API更容易使用.
ACE倾向于更"经典的OO",而提升往往来自C++标准库的设计.例如,在ACE中启动一个线程需要创建一个从ACE_Task派生的新类,并覆盖在线程运行时调用的虚拟svc()函数.在boost中,您可以创建一个线程并运行您想要的任何功能,这种功能明显较少.
帮自己一个忙,避开ACE.如果你问我,这是一个可怕的,可怕的图书馆.我已经工作了(或者更确切地说是HAD与它一起工作了3年)而且我告诉你它是一个设计糟糕,记录不良,使用过时的C++并且完全依赖于脑死亡的设计决策而实施得很糟糕的垃圾... "C with classes"实际上是在帮助它.如果你研究一些构造的内部实现,你通常很难抑制你的呕吐反射.另外,我不能强调"糟糕的文档"方面.通常,ACE的记录功能的概念包括简单地打印功能的签名.至于它的论证的意义,它的回报价值及其一般行为,你通常只能自己解决这个问题.我厌倦了不得不猜测函数可能会抛出哪些异常,哪个返回值表示成功,我必须传递哪些参数才能使函数执行我需要它做的事情或者函数/类是否是线程安全的或不.
另一方面,提升,使用简单,现代C++,非常有文档记录,它只是工作!使用ACE可以提升Boost!
不要担心线程和同步对象上的OS抽象层的开销.字面上的线程开销根本不重要(因为它只适用于线程创建,与异步指针间接开销相比,这已经非常慢).如果您发现互斥操作正在减慢您的速度,那么您最好关注原子操作或重新安排数据访问模式以避免争用.
关于提升与ACE,这是"新风格"与"旧式"编程的问题.Boost有很多仅基于模板的模板恶作剧(如果你能欣赏它,它们很漂亮).另一方面,如果你已经习惯了"C with classes"风格的C++,ACE会感觉更自然.我认为这主要取决于你的团队的个人品味.
我已将ACE用于众多重型生产服务器.它永远不会让我失望.它坚如磐石,现在已经做了很多年.试图学习BOOST的ASIO网络框架 - 无法掌握它.虽然BOOST是更"现代"的C++,但它也更难用于非平凡的任务 - 没有"现代"的C++经验和深入的STL知识,很难正确使用
即使ACE是一种旧式C++,它仍然具有许多面向线程的功能,而这些功能尚未提供.
目前我认为没有理由不同时使用两者(但出于不同的目的).一旦boost提供了在任务之间实现消息队列的简单方法,我可以考虑放弃ACE.
京公网安备 11010802040832号 | 京ICP备19059560号-6 