【问题标题】:Does multithreaded memory access improve performance?多线程内存访问会提高性能吗?
【发布时间】:2012-03-05 03:14:30
【问题描述】:

我在 RAM 中有一个大数组,并希望尽可能快地从中读取数据。忽略任何可能的同步,我只是想知道理论。

将这些读取分散到多个线程上是否比仅使用一个线程更快?

编辑:每个数据点大约 20KB,我无法预测它们的读取顺序。

【问题讨论】:

    标签: multithreading performance memory


    【解决方案1】:

    一般来说:可以,但小心缓存未命中

    假设您有一个 int[]:考虑将其划分为后续元素的范围,并让每个线程都有自己的范围(线程 1 从 0 到 127,线程 2 从 128 到 255,...)。

    当您读取数组的一个元素时,执行加载的处理器内核最有可能将数组的一些连续元素加载到其 缓存 中,因为大多数时候它们都在在 (immagine for (int i =0;;i++) do(arra[i])): 如果您不将数据分区为 粗略 那样的话,所有这些工作都将被浪费掉。

    您可以在 Joe Duffy 的以下文章中了解更多相关信息:

    不严格相关:The 'premature optimization is evil' myth 尤其是“了解重要的数量级”部分

    正如@Alex 所说,一般规则是您必须始终衡量并且永远不要假设任何事情:通过并发实现高效可扩展性是一个复杂的主题,需要对底层架构有很多深入的了解。

    【讨论】:

    • 我认为数据局部性没有多大用处,因为我的元素很大并且以随机方式访问。但这是否意味着如果数据存在于内存的不同部分,处理器和内存之间的连接允许并行执行读取?
    • 好吧,如果你的数据点是那个大小,答案肯定是肯定的!请记住将数组元素填充到最接近的处理器字长倍数(有时可能会出现严重的不对齐)。
    • 如果数据存在于内存的不同部分,处理器和内存之间的连接是否允许并行执行读取?
    • 我认为是这样,这取决于前端总线/北桥的架构。我不是专家,但我发现了一些有趣的文章:en.wikipedia.org/wiki/Memory_controlleren.wikipedia.org/wiki/Front-side_bus#Transfer_rates 该层的带宽很大:)
    • 多线程情况下局部性的另一面是错误共享。除了希望每个线程尽可能处理粗块以便每个线程都享有更好的局部性之外,您也不希望线程 0 在线程 1 可能正在读取或写入位置 x+1 时写入位置 x,如果 x 和x+1 将在同一个缓存行中,或者线程 0 将导致线程 1 的缓存行需要刷新,即使它关心的值不会改变。随着更多内核的添加,这种错误共享会导致行为呈指数级恶化。
    【解决方案2】:

    只需针对您的具体情况进行测试。毕竟线程的上下文切换是昂贵的。使用单线程方法可能也一样快。

    衡量性能,不要猜测。

    【讨论】:

    • 我做了一个简单的测试,但结果尚无定论 - 有时我获得了性能提升,而其他时候则完全没有。这就是我想知道这个理论的原因。
    • 您是否考虑过“jit-warmup”和可比较/可测量的测试运行?如果您可以发布您的测试代码,那肯定会有所帮助。
    • 是的,该测试肯定可以通过适当的 JIT 预热和多次测试运行的平均值进行一些改进。代码非常丑陋,我并不想传播它,但我会进行这些更改并稍后再次运行测试。谢谢!
    【解决方案3】:

    技术上是的。您可以使用更多线程从内存中的不同位置读取。 CPU 速度更快,因此它可以发出大量读取,例如每个线程读取一次,直到第一次读取的结果返回。然后开始处理请求。 假设 RAM 没有阻塞,这是可行的;即支持一次多次读取。例如,你的内存只有 1 条输入线和 1 条输出线,那么它就会阻塞,没有多少线程会有所帮助。

    现在请记住,您对读取的数据究竟做了什么。如果您通过网络同步发送或将其转储到 HDD,这并不一定意味着您应该使用多线程来读取数据,因为它会成为 write_to_HDD/sendData 的瓶颈。

    如果您有另一个 CPU 等待处理检索到的数据,那么您可以很好地瘫痪。同时读取和处理。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-08-13
      • 1970-01-01
      • 2011-05-18
      • 1970-01-01
      相关资源
      最近更新 更多