【问题标题】:Initializing Billion Integers to value 1将十亿整数初始化为值 1
【发布时间】:2012-01-10 18:33:55
【问题描述】:

在具有 32GB DRAM 的 linux 平台 8 核 CPU 上使用 c/c++ 初始化十亿个整数的 posix 线程设计是什么? 感谢您的帮助。

【问题讨论】:

  • 10 亿 == 1G;整数 ~~ 4GB (8GB, 16GB?); 32MB 太少了 waaaaaaaaaaaaaay
  • 只是想知道:如果瓶颈是内存 b/w,我认为多线程可能会更慢?您是否检查过性能是否受到内存带宽或初始值计算的限制?嗯,好吧,也许您可​​以同时写入多个不同的 RAM 区域并获得更快的结果..有人知道一些细节吗?
  • @zerm,回答这个问题 - 对于这样一个微不足道的操作,内存带宽肯定会成为瓶颈,一个线程将是最快的。
  • 从昨天开始,我在下载的一本书中读到了同样的情况,书名为《每个程序员应该知道的关于内存的知识》。还没完。但也许它会给你你正在寻找的答案。
  • @MarkRansom Heh,我猜为时已晚;)

标签: c++ c linux performance


【解决方案1】:

也许是divide and conquer algorithm?将包含整数的内存按与系统最佳线程数相对应的某个数字进行分区。然后为每个分区启动一个线程,初始化其所有整数。

【讨论】:

  • 问题是多少线程? 8 个线程是否足够,或者 16 个或多少个?如果我们使用许多线程(> 100),我认为性能会对 Linux 产生不利影响。
  • @TiborJiri:线程数取决于许多几乎完全与目标系统相关的因素。您可能需要进行一些测试才能找到正确的值,但您可以设计算法,使数字成为一个可以简单更改的参数。
  • @Tibor:maerics 说了什么,您可能想查看stackoverflow.com/questions/1715580/… 以获得与 Mac 相关的答案。它可能会帮助您搜索与您的平台相关的答案。
  • 为什么投反对票?我意识到 memcpy 解决方案更好,但 OP 特别要求提供多线程解决方案......
【解决方案2】:

线程的确切数量不会是这样一个限制因素,但有时对于这个问题,值得过度使用,比如每个物理内核使用 2 个线程。

但真正的瓶颈是 IO,将数据写入 RAM。您必须注意要替换的数据在删除之前永远不会读取。然后你应该确保对内存的写入出现在大块中,并且(如果可能的话)作为“直写”,现代 CPU 有后面的指令。

通常像memcpy 这样的带有固定大小的缓冲区(某些页面),其中包含您想要查看的模式,应该得到很好的优化。

【讨论】:

    【解决方案3】:

    这是一个微不足道的操作,您无需考虑多线程。只需在单个线程中使用 memcpy 即可。

    【讨论】:

    • 因为我知道整数是连续的,我也可以使用 memset() 在单线程中初始化为 1,谢谢大卫!
    • @TiborJiri 您希望如何使用memset 初始化整数(不为 0)。试试std::fill
    • @JamesKanze,你说得对,memset 不能初始化整数,但我怀疑std::fill 不是最快的方法。
    • 这个解决方案可能会提供最好的性价比。
    • @MarkRansom 如果这不是最快的解决方案,那么库和/或编译器存在严重问题。
    【解决方案4】:

    如果您确实尝试多线程,将写入与本机缓存行大小对齐可能会提供最佳内存吞吐量。正如大家所说,内存吞吐量将主导性能,但这些写入需要一部分 CPU 时间。使用多线程和矢量化指令最大限度地减少时间可能会有所帮助。

    真正的答案是分析您的系统(因为您声明了一个非常具体的目标,听起来您不想设计一个对大多数目标来说足够好的平衡算法)。可以访问 32GB DRAM 的现代 CPU 通常具有硬件性能计数器(英特尔和 AMD 有),这使得查找 CPU、缓存活动变得非常容易。

    【讨论】:

      【解决方案5】:

      那是为了什么?根据使用情况,以下场景可能会起作用:您将一个内存页(即数 KB)初始化为全 1。然后,您可以根据需要使用写时复制标志将该页面多次映射到虚拟地址空间。这样,在读取时您将从所有这些虚拟页面中获取所有内容,在写入系统时将根据需要分配更多物理页面。

      【讨论】:

        猜你喜欢
        • 2015-05-16
        • 1970-01-01
        • 2021-01-23
        • 2016-02-01
        • 2021-08-13
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多