【问题标题】:High performance alternatives to STL?STL 的高性能替代品?
【发布时间】:2011-11-23 01:17:38
【问题描述】:

传统 STL 有哪些缓存友好的高性能替代方案。 它们应该针对现代 64 位 Intel/AMD CPU 的缓存进行优化。

我不是在寻找基于官方标准的 STL 实现,它不一定是基于该标准的,或者是具有高性能数据结构的扩展 STL。或者只是一个提供通用数据结构(如列表、地图等)的库。

高并发和无锁数据结构将是一个好处。

我对链接和许可证感兴趣。

我已经阅读过 EASTL 并且之前使用过 Boost。

目前,游戏开发人员和科学界正在使用什么来充分利用 CPU?管道中有什么?

【问题讨论】:

  • 确实如此。我们现在可以将 GPU 用于图形以外的用途
  • 好吧,如果我是你,我不会问科学计算的人。至少不是那些仍在使用 fortran 的,并声称它比 C 更快...

标签: c++ stl


【解决方案1】:

+1 表示 EASTL。

任何基于 C++11 兼容编译器的东西都可能会因为移动语义而表现得更好。

使用-std=c++0x 的 GNU libstdc++ 实现已经可以看到这种差异

对于并发/无锁容器我推荐:

  • libCds by Max Khiszinsky
  • 来自英特尔的 TBB(无实践经验)

我的核心建议是这样的:

优化标准库主要是决定如何正确使用算法/容器的一个因素,而不是寻找“完美”的实现。 STL 是通用的,永远不会有完美的实现。

只需密切注意您的返回值/输出参数(更喜欢使用输出迭代器,并使用transformpartial_sumaccumulate 进入一个适当调用了reserveresize 的容器;定义swap 用于您的元素类型等)

【讨论】:

  • +1:你不能同时拥有“通用”和“完美用于特定目的”
  • 有趣的是你对 c++11 中移动语义的看法。这是在 Visual Studio 2011 中实现的吗?
  • @MattH,Visual Studio 2010 支持移动语义,标准库实现利用了它。
【解决方案2】:

我相信标准模板自适应并行库STAPL 很可能是目前最重要的研究合作之一。

Microsoft 正在为Asynchronous Agents Library 投入大量精力,该Asynchronous Agents Library 拥有许多经过良好测试的高性能消息传递容器。

英特尔有自己的产品Thread Building Blocks,其中包含许多用于并行处理的容器和算法。

【讨论】:

  • 作为记录,我觉得这是一个很好的补充;除了 TBB,这些对我来说仍然是未知的,+1 在我身上:)
【解决方案3】:

Boost Compute 绝对是亚军。

http://boostorg.github.io/compute/

【讨论】:

    猜你喜欢
    • 2020-05-28
    • 2021-09-03
    • 1970-01-01
    • 2019-05-15
    • 1970-01-01
    • 2014-07-13
    • 1970-01-01
    • 2011-07-23
    • 2021-05-07
    相关资源
    最近更新 更多