Linux上的两个标准库之间是否有任何综合性能比较?
我已经搜索了很长时间但却一无所获。
编译器将为clang
,因为Linux上的libc++
仅适用于clang
。
libc++
在Linux上没有完整功能(exception_ptr
尚未实现,但我不关心它)。另一方面,它具有比libstdc++
更多的C ++ 11/14功能。较新版本的libstdc++
确实提供了更多支持(例如,GCC 4.9中的regex
),但要求clang
使用除发行版默认值之外的新版本有点困难。它可以做到,但我还没有发现任何非丑陋的解决方案。
很容易在自定义位置安装较新的GCC并构建可执行文件以链接到较新的libstdc++
,但我不知道如何让exec选择新库在运行时而不将新库注入LD_LIBRARY_PATH
,这会改变系统中使用C ++的所有内容的行为。 RPATH
是一个可能的解决方案,但我认为它非常难看,也许我错了,它也改变了同一个可执行文件链接到的其他库的行为。
以上是我想切换到libc++
的主要原因(更好的C ++ 11/14支持而不会弄乱系统可执行文件,旧的libstdc++
仅链接到ABI支持)。但是,我关注的是表现。我想在性能比较中看到一些事情(另一个原因是我发现报告libc++
的错误要容易得多。在发生错误时阅读libc++
的来源是相当的令人愉快的是,编码非常整洁,在阅读libstdc++
的来源时,我发现我经常失败了):
vector
,性能(resize
,push_back
等等,有时它们无法避免)<random>
(<cmath>
是不相关的,我相信这两个库没有区别,因为它只依赖于系统libm
,这在Linux上非常慢且过时,无论如何我都不会使用glibc
的数学库)<algorithm>
,std::copy
,std::fill
等等。有些时候你无法避免它们(主要是当你想要提供的界面是通用的而你不想要的时候专门指定显式调用memset
等指针的每个函数。因此,最好知道库是否在这些函数上具有性能(例如,实现的开销是否足够低,以至于它允许编译器查看正在进行的操作,因此可以执行某些优化仅适用于指针.I认为这也取决于STL的迭代器实现。)