【问题标题】:How to optimize for dual, quad and higher multi-processors?如何针对双、四和更高的多处理器进行优化?
【发布时间】:2011-12-26 04:42:19
【问题描述】:

伙计们,我已经编写了 20 多年的高速软件,并且几乎知道书中的每一个技巧,从微基准制作合作、分析、用户模式多任务处理、尾递归,你可以将其命名为非常高性能的东西Linux、Windows 等。

问题在于,当 CPU 密集型工作的多个线程暴露于多核处理器时会发生什么,我感到很困惑。

在线程之间(在不同内核上)共享日期的各种方式的微观基准测试中的性能结果似乎不符合逻辑。

很明显,内核之间存在一些“隐藏的交互”,这在我自己的编程代码中并不明显。我听说过 L1 缓存和其他问题,但这些对我来说是不透明的。

问题是:我在哪里可以学到这些东西?我正在寻找一本关于多核处理器如何工作、如何编程以利用其内存缓存或其他硬件架构而不是被它们惩罚的深度书籍。

有什么建议或很棒的网站或书籍吗?经过大量谷歌搜索后,我空空如也。

真诚地, 韦恩

【问题讨论】:

  • 我认为很大程度上取决于您要完成的工作。服务器端与桌面,图形与文本处理与模拟核爆炸;几十个任务的高吞吐量 vs. 10,000 个任务的低延迟。您有什么特别感兴趣的领域吗?
  • 好的。好问题。本质上,我们正在构建一个 CEP(复杂事件处理)系统,该系统必须以软实时方式每秒处理数百万小比特数据。从理论上讲,单核性能表明,通过将 X 4 乘以四核或 X 8,可以实现必要的性能。数据需要从不同的来源流向组合,然后以不同的方式相乘到客户端。每个步骤都需要 CPU 处理或 I/O,因此我们使用 Interlocked 构建了无锁协作用户模式多任务。但是存在无法解释的(迄今为止)性能问题。
  • 您可能会研究的另一件事:1024cores.net/home/parallel-computing/taxi-paths/…

标签: c# .net parallel-processing cpu


【解决方案1】:

这本书教会了我很多关于为什么原始 CPU 功率不是唯一需要注意的问题的问题。几年前我在研究生院使用它,但我认为所有原则仍然适用:

http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704901

本质上,多进程配置中的一个主要问题是同步对主内存的访问,如果您不正确执行此操作,它可能会成为性能的真正瓶颈。必须保持同步的缓存非常复杂。

【讨论】:

  • 是的,这就是他需要的书。见特别。第 4 章。
  • 是的,这个似乎涵盖了所有内容,删除了我的帖子。
  • 显示我的年龄,我的这本书实际上是我在斯坦福大学 Hennessey 的建筑课时得到的这本书的预发行版本。他是一位非常好的老师。毫不奇怪,他继续担任大学校长。
  • 弗朗西斯,您对这本书的看法似乎触及了最关键的问题。我会看看这本书。如果这就是你们所说的,那么我会选择你作为正确的答案,弗朗西斯。
【解决方案2】:

我自己的问题和答案,在 stackoverflow 的姊妹网站上:https://softwareengineering.stackexchange.com/questions/126986/where-can-i-find-an-overview-of-known-multithreading-design-patterns/126993#126993

我将复制答案以避免需要点击:

引用鲍里斯:

使用 Microsoft .NET 进行并行编程:设计模式 多核架构上的分解与协调https://rads.stackoverflow.com/amzn/click/0735651590

这是一本书,我全心推荐。

它是:

新 - 去年发布。意味着你没有阅读有些过时 实践。

短 - 大约 200 多页,信息密集。这些 天读的太多,读的时间太少 1000+ 页 书。

易于阅读-不仅写得很好,而且 以非常简单易读的方式介绍了难以掌握的概念。

旨在教学 - 每章都提供练习。我知道它是 做这些总是有益的,但很少做。这本书给出了非常 引人注目和有趣的任务。令人惊讶的是,我做了其中的大部分,并且 喜欢这样做。

此外,如果您想了解更多底层细节,这是我找到的最佳资源:“The Art of Multiprocessor Programming”它是使用 java 作为他们的代码示例编写的,与我的 C# 背景很相配。

PS:我有大约 5 年的“硬核”并行编程经验,(教唆使用 C#)所以当我说“The Art of Multiprocessor Programming”摇滚时,希望你能相信我

【讨论】:

    【解决方案3】:

    【讨论】:

      【解决方案4】:

      并行化代码中出现意外糟糕结果的一个具体原因是false sharing,如果您不知道那里发生了什么(我不知道),您将不会看到它的到来。这里有两篇文章讨论了.Net的原因和补救措施:

      http://msdn.microsoft.com/en-us/magazine/cc872851.aspx

      http://www.codeproject.com/KB/threads/FalseSharing.aspx

      Rgds GJ

      【讨论】:

      • 它声称可以解决问题,但仅当所有数据都包含在单个对象中(在本例中为值类型数组)时才会这样做。 .NET 让您无法控制不同对象的存储,您需要使用本机代码来避免在复杂的现实世界场景中进行错误共享。
      • 您对对象所在的位置几乎没有控制权是对的,但是您可以推测数据何时在内存中靠近在一起(相同的对象或数组中)。然后您可以控制如何在线程/任务之间划分工作,因此它们不会对相邻数据进行操作。这应该可以让您最大限度地减少问题。
      【解决方案5】:

      多线程的不同方面需要不同的方法。

      例如,在网络服务器上,线程池的使用被广泛使用,因为它被认为“有利于”性能。这样的池可能包含数百个等待投入工作的线程。使用这么多线程会导致调度程序超时工作,这对性能不利,但在 Linux 系统上无法避免。对于 Windows,选择的方法是 IOCP 机制,它建议线程数不大于安装的内核数。它使应用程序变为(I/O 完成)事件驱动,这意味着轮询时不会浪费任何周期。所涉及的少数线程将调度程序的工作量降至最低。

      如果目标是实现可扩展的功能(更多内核 更高性能),那么主要问题将是内存总线饱和。由于取码、数据读取和数据写入,会出现饱和。一个不正确实现的代码在两个线程上运行会比一个线程运行得慢。解决这个问题的唯一方法是通过主动减少内存总线的工作:

      • 将代码定制为最小的内存占用(= 适合代码缓存)并且不会调用其他函数或到处跳转。
      • 将内存读写调整为最小大小。
      • 通知即将到来的 RAM 读取的预取机制。
      • 调整工作,使内核自己的缓存(L1 和 L2)内部执行的工作与它们外部的工作(L3 和 RAM)相比尽可能大。

      换句话说:将适用的代码和数据块放入尽可能少的缓存行(每个 64 字节),因为最终这将决定可扩展性。如果高速缓存/内存系统每秒能够进行 x 次高速缓存行操作,那么如果其要求每个工作单元有 5 个高速缓存行(=> x/5)而不是 11 个(x/11)或 52 个,那么您的代码将运行得更快(x/52)。

      实现这一点并非易事,因为它每次都需要或多或少独特的解决方案。一些编译器在指令排序方面做得很好,以利用主处理器的流水线。这并不一定意味着它会是多核的良好排序。

      可扩展代码的有效实现不一定是漂亮的。推荐的编码技术和风格最终可能会阻碍代码的执行。

      我的建议是通过使用低级语言(例如 C)编写一个简单的多线程应用程序来测试其工作原理,该应用程序可以调整为在单线程或多线程模式下运行,然后分析代码以用于不同的模式。您将需要在指令级别分析代码。然后,您尝试使用不同的 (C) 代码结构、数据组织等。您可能必须跳出框框思考并重新考虑算法,以使其对缓存更加友好。

      第一次需要做很多工作。您不会了解什么适用于所有多线程解决方案,但您可能会大致了解什么是不该做的,以及在分析分析代码时要寻找什么指示。

      【讨论】:

        【解决方案6】:

        我发现这个链接专门解释了 影响我的 CPU 上的多核缓存处理 多线程程序。

        http://www.multicoreinfo.com/research/intel/mem-issues.pdf

        网站 multicoreinfo.com 通常有很多好东西 有关多核编程的信息和参考。

        【讨论】:

        • 哇,一篇关于虚假共享的文章,不过是针对 c++ 的。你真是太聪明了,自己解决了这一切!
        猜你喜欢
        • 2017-09-06
        • 2011-03-22
        • 2018-08-04
        • 1970-01-01
        • 2013-01-18
        • 2011-05-14
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多