我们最近购买了一些新的服务器，并且正在经历糟糕的memcpy性能 . 与我们的笔记本电脑相比，服务器上的memcpy性能要慢3倍 .
Server Specs
-
底盘和Mobo：SUPER MICRO 1027GR-TRF
-
CPU：2x Intel Xeon E5-2680 @ 2.70 Ghz
-
内存：8x 16GB DDR3 1600MHz
编辑：我也在另一台具有更高规格的服务器上进行测试，并看到与上述服务器相同的结果
Server 2 Specs
-
底盘和Mobo：SUPER MICRO 10227GR-TRFT
-
CPU：2x Intel Xeon E5-2650 v2 @ 2.6 Ghz
-
内存：8x 16GB DDR3 1866MHz
Laptop Specs
-
机箱：联想W530
-
CPU：1x Intel Core i7 i7-3720QM @ 2.6Ghz
-
内存：4x 4GB DDR3 1600MHz
Operating System
$ cat /etc/redhat-release
Scientific Linux release 6.5 (Carbon)
$ uname -a
Linux r113 2.6.32-431.1.2.el6.x86_64 #1 SMP Thu Dec 12 13:59:19 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
Compiler (on all systems)
$ gcc --version
gcc (GCC) 4.6.1
还根据@stefan的建议使用gcc 4.8.2进行了测试 . 编译器之间没有性能差异 .
Test Code 下面的测试代码是一个 jar 装测试，用于复制我在 生产环境 代码中看到的问题 . 我知道这个基准是简单的，但它能够利用和识别我们的问题 . 代码在它们之间创建两个1GB缓冲区和memcpys，为memcpy调用计时 . 您可以使用以下命令在命令行上指定备用缓冲区大小：./ big_memcpy_test [SIZE_BYTES]
#include <chrono>
#include <cstring>
#include <iostream>
#include <cstdint>
class Timer
{
public:
Timer()
: mStart(),
mStop()
{
update();
}
void update()
{
mStart = std::chrono::high_resolution_clock::now();
mStop = mStart;
}
double elapsedMs()
{
mStop = std::chrono::high_resolution_clock::now();
std::chrono::milliseconds elapsed_ms =
std::chrono::duration_cast<std::chrono::milliseconds>(mStop - mStart);
return elapsed_ms.count();
}
private:
std::chrono::high_resolution_clock::time_point mStart;
std::chrono::high_resolution_clock::time_point mStop;
};
std::string formatBytes(std::uint64_t bytes)
{
static const int num_suffix = 5;
static const char* suffix[num_suffix] = { "B", "KB", "MB", "GB", "TB" };
double dbl_s_byte = bytes;
int i = 0;
for (; (int)(bytes / 1024.) > 0 && i < num_suffix;
++i, bytes /= 1024.)
{
dbl_s_byte = bytes / 1024.0;
}
const int buf_len = 64;
char buf[buf_len];
// use snprintf so there is no buffer overrun
int res = snprintf(buf, buf_len,"%0.2f%s", dbl_s_byte, suffix[i]);
// snprintf returns number of characters that would have been written if n had
// been sufficiently large, not counting the terminating null character.
// if an encoding error occurs, a negative number is returned.
if (res >= 0)
{
return std::string(buf);
}
return std::string();
}
void doMemmove(void* pDest, const void* pSource, std::size_t sizeBytes)
{
memmove(pDest, pSource, sizeBytes);
}
int main(int argc, char* argv[])
{
std::uint64_t SIZE_BYTES = 1073741824; // 1GB
if (argc > 1)
{
SIZE_BYTES = std::stoull(argv[1]);
std::cout << "Using buffer size from command line: " << formatBytes(SIZE_BYTES)
<< std::endl;
}
else
{
std::cout << "To specify a custom buffer size: big_memcpy_test [SIZE_BYTES] \n"
<< "Using built in buffer size: " << formatBytes(SIZE_BYTES)
<< std::endl;
}
// big array to use for testing
char* p_big_array = NULL;
/////////////
// malloc
{
Timer timer;
p_big_array = (char*)malloc(SIZE_BYTES * sizeof(char));
if (p_big_array == NULL)
{
std::cerr << "ERROR: malloc of " << SIZE_BYTES << " returned NULL!"
<< std::endl;
return 1;
}
std::cout << "malloc for " << formatBytes(SIZE_BYTES) << " took "
<< timer.elapsedMs() << "ms"
<< std::endl;
}
/////////////
// memset
{
Timer timer;
// set all data in p_big_array to 0
memset(p_big_array, 0xF, SIZE_BYTES * sizeof(char));
double elapsed_ms = timer.elapsedMs();
std::cout << "memset for " << formatBytes(SIZE_BYTES) << " took "
<< elapsed_ms << "ms "
<< "(" << formatBytes(SIZE_BYTES / (elapsed_ms / 1.0e3)) << " bytes/sec)"
<< std::endl;
}
/////////////
// memcpy
{
char* p_dest_array = (char*)malloc(SIZE_BYTES);
if (p_dest_array == NULL)
{
std::cerr << "ERROR: malloc of " << SIZE_BYTES << " for memcpy test"
<< " returned NULL!"
<< std::endl;
return 1;
}
memset(p_dest_array, 0xF, SIZE_BYTES * sizeof(char));
// time only the memcpy FROM p_big_array TO p_dest_array
Timer timer;
memcpy(p_dest_array, p_big_array, SIZE_BYTES * sizeof(char));
double elapsed_ms = timer.elapsedMs();
std::cout << "memcpy for " << formatBytes(SIZE_BYTES) << " took "
<< elapsed_ms << "ms "
<< "(" << formatBytes(SIZE_BYTES / (elapsed_ms / 1.0e3)) << " bytes/sec)"
<< std::endl;
// cleanup p_dest_array
free(p_dest_array);
p_dest_array = NULL;
}
/////////////
// memmove
{
char* p_dest_array = (char*)malloc(SIZE_BYTES);
if (p_dest_array == NULL)
{
std::cerr << "ERROR: malloc of " << SIZE_BYTES << " for memmove test"
<< " returned NULL!"
<< std::endl;
return 1;
}
memset(p_dest_array, 0xF, SIZE_BYTES * sizeof(char));
// time only the memmove FROM p_big_array TO p_dest_array
Timer timer;
// memmove(p_dest_array, p_big_array, SIZE_BYTES * sizeof(char));
doMemmove(p_dest_array, p_big_array, SIZE_BYTES * sizeof(char));
double elapsed_ms = timer.elapsedMs();
std::cout << "memmove for " << formatBytes(SIZE_BYTES) << " took "
<< elapsed_ms << "ms "
<< "(" << formatBytes(SIZE_BYTES / (elapsed_ms / 1.0e3)) << " bytes/sec)"
<< std::endl;
// cleanup p_dest_array
free(p_dest_array);
p_dest_array = NULL;
}
// cleanup
free(p_big_array);
p_big_array = NULL;
return 0;
}
CMake File to Build
project(big_memcpy_test)
cmake_minimum_required(VERSION 2.4.0)
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
# create verbose makefiles that show each command line as it is issued
set( CMAKE_VERBOSE_MAKEFILE ON CACHE BOOL "Verbose" FORCE )
# release mode
set( CMAKE_BUILD_TYPE Release )
# grab in CXXFLAGS environment variable and append C++11 and -Wall options
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -Wall -march=native -mtune=native" )
message( INFO "CMAKE_CXX_FLAGS = ${CMAKE_CXX_FLAGS}" )
# sources to build
set(big_memcpy_test_SRCS
main.cpp
)
# create an executable file named "big_memcpy_test" from
# the source files in the variable "big_memcpy_test_SRCS".
add_executable(big_memcpy_test ${big_memcpy_test_SRCS})
Test Results
Buffer Size: 1GB | malloc (ms) | memset (ms) | memcpy (ms) | NUMA nodes (numactl --hardware)
---------------------------------------------------------------------------------------------
Laptop 1 | 0 | 127 | 113 | 1
Laptop 2 | 0 | 180 | 120 | 1
Server 1 | 0 | 306 | 301 | 2
Server 2 | 0 | 352 | 325 | 2
正如您所看到的，我们服务器上的memcpys和memset比我们笔记本电脑上的memcpys和memset要慢得多 .
Varying buffer sizes
我尝试过从100MB到5GB的缓冲区都有类似的结果（服务器比笔记本电脑慢）
NUMA Affinity
我读到了与NUMA有性能问题的人，所以我尝试使用numactl设置CPU和内存亲和力，但结果保持不变 .
服务器NUMA硬件
$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 65501 MB
node 0 free: 62608 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 65536 MB
node 1 free: 63837 MB
node distances:
node 0 1
0: 10 21
1: 21 10
笔记本电脑NUMA硬件
$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 16018 MB
node 0 free: 6622 MB
node distances:
node 0
0: 10
设置NUMA亲和力
$ numactl --cpunodebind=0 --membind=0 ./big_memcpy_test
任何帮助解决这个问题非常感谢 .
Edit: GCC Options
根据评论，我尝试使用不同的GCC选项进行编译：
使用-march和-mtune进行编译设置为native
g++ -std=c++0x -Wall -march=native -mtune=native -O3 -DNDEBUG -o big_memcpy_test main.cpp
结果：完全相同的性能（没有改进）
使用-O2而不是-O3进行编译
g++ -std=c++0x -Wall -march=native -mtune=native -O2 -DNDEBUG -o big_memcpy_test main.cpp
结果：完全相同的性能（没有改进）
Edit: Changed memset to write 0xF instead of 0 to avoid NULL page (@SteveCox)
使用0以外的值进行memset时没有改进（在这种情况下使用0xF） .
Edit: Cachebench results
为了排除我的测试程序过于简单，我下载了一个真正的基准测试程序LLCacheBench（http://icl.cs.utk.edu/projects/llcbench/cachebench.html）
我分别在每台机器上构建了基准测试，以避免架构问题 . 以下是我的结果 .
请注意，在较大的缓冲区大小上，性能差异很大 . 测试的最后一个尺寸（16777216）在笔记本电脑上以18849.29 MB /秒和在服务器上以6710.40执行 . 这是性能差异的3倍 . 您还可以注意到服务器的性能下降比笔记本电脑更陡峭 .
Edit: memmove() is 2x FASTER than memcpy() on the server
基于一些实验，我尝试在我的测试用例中使用memmove（）而不是memcpy（），并在服务器上找到了2倍的改进 . 笔记本电脑上的Memmove（）运行速度比memcpy（）慢，但奇怪的是运行速度与服务器上的memmove（）相同 . 这引出了一个问题，为什么memcpy这么慢？
更新了代码以测试memmove和memcpy . 我必须将memmove（）包装在一个函数中，因为如果我离开它内联GCC优化它并执行与memcpy（）完全相同（我假设gcc将其优化为memcpy，因为它知道位置没有重叠） .
更新结果
Buffer Size: 1GB | malloc (ms) | memset (ms) | memcpy (ms) | memmove() | NUMA nodes (numactl --hardware)
---------------------------------------------------------------------------------------------------------
Laptop 1 | 0 | 127 | 113 | 161 | 1
Laptop 2 | 0 | 180 | 120 | 160 | 1
Server 1 | 0 | 306 | 301 | 159 | 2
Server 2 | 0 | 352 | 325 | 159 | 2
Edit: Naive Memcpy
根据@Salgar的建议，我已经实现了我自己的天真memcpy功能并对其进行了测试 .
天真的Memcpy来源
void naiveMemcpy(void* pDest, const void* pSource, std::size_t sizeBytes)
{
char* p_dest = (char*)pDest;
const char* p_source = (const char*)pSource;
for (std::size_t i = 0; i < sizeBytes; ++i)
{
*p_dest++ = *p_source++;
}
}
天真的Memcpy结果与memcpy（）相比
Buffer Size: 1GB | memcpy (ms) | memmove(ms) | naiveMemcpy()
------------------------------------------------------------
Laptop 1 | 113 | 161 | 160
Server 1 | 301 | 159 | 159
Server 2 | 325 | 159 | 159
Edit: Assembly Output
简单的memcpy源码
#include <cstring>
#include <cstdlib>
int main(int argc, char* argv[])
{
size_t SIZE_BYTES = 1073741824; // 1GB
char* p_big_array = (char*)malloc(SIZE_BYTES * sizeof(char));
char* p_dest_array = (char*)malloc(SIZE_BYTES * sizeof(char));
memset(p_big_array, 0xA, SIZE_BYTES * sizeof(char));
memset(p_dest_array, 0xF, SIZE_BYTES * sizeof(char));
memcpy(p_dest_array, p_big_array, SIZE_BYTES * sizeof(char));
free(p_dest_array);
free(p_big_array);
return 0;
}
装配输出：这在服务器和笔记本电脑上完全相同 . 我节省空间而不是粘贴两者 .
.file "main_memcpy.cpp"
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB25:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl $1073741824, %edi
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
call malloc
movl $1073741824, %edi
movq %rax, %rbx
call malloc
movl $1073741824, %edx
movq %rax, %rbp
movl $10, %esi
movq %rbx, %rdi
call memset
movl $1073741824, %edx
movl $15, %esi
movq %rbp, %rdi
call memset
movl $1073741824, %edx
movq %rbx, %rsi
movq %rbp, %rdi
call memcpy
movq %rbp, %rdi
call free
movq %rbx, %rdi
call free
addq $8, %rsp
.cfi_def_cfa_offset 24
xorl %eax, %eax
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE25:
.size main, .-main
.ident "GCC: (GNU) 4.6.1"
.section .note.GNU-stack,"",@progbits
PROGRESS!!!! asmlib
根据@tbenson的建议，我尝试使用memcpy的asmlib版本运行 . 我的结果最初很差但是在将SetMemcpyCacheLimit（）更改为1GB（我的缓冲区的大小）后，我的速度与我的天真for循环相同！
坏消息是memmove的asmlib版本比glibc版本慢，它现在运行在300ms标记（与glibc版本的memcpy相同） . 奇怪的是，在我的SetMemcpyCacheLimit（）大量的笔记本电脑上它会伤害性能......
在下面的结果中，标有SetCache的行将SetMemcpyCacheLimit设置为1073741824.没有SetCache的结果不调用SetMemcpyCacheLimit（）
使用asmlib函数的结果：
Buffer Size: 1GB | memcpy (ms) | memmove(ms) | naiveMemcpy()
------------------------------------------------------------
Laptop | 136 | 132 | 161
Laptop SetCache | 182 | 137 | 161
Server 1 | 305 | 302 | 164
Server 1 SetCache | 162 | 303 | 164
Server 2 | 300 | 299 | 166
Server 2 SetCache | 166 | 301 | 166
开始倾向于缓存问题，但是会导致什么呢？
7 回答
[我会将此作为评论，但没有足够的声誉这样做 . ]
我有一个类似的系统，看到类似的结果，但可以添加一些数据点：
如果你颠倒了天真的方向
memcpy（即转换为*p_dest-- = *p_src--），那么你可能会比前进方向的性能差得多（对我来说约为637毫秒） . glibc 2.12中的memcpy()发生了变化，暴露了在重叠缓冲区（http://lwn.net/Articles/414467/）上调用memcpy的几个错误，我认为问题是由切换到向后运行的memcpy版本引起的 . 因此，后向和前向副本可以解释memcpy()/memmove()差异 .不使用非临时商店似乎更好 . 许多优化的实现切换到大缓冲区（即大于最后一级缓存）的非临时存储（未缓存） . 我测试了Agner Fog的memcpy版本（http://www.agner.org/optimize/#asmlib），发现它与
glibc中的版本大致相同 . 但是，asmlib有一个函数（SetMemcpyCacheLimit），它允许设置阈值，高于该阈值时使用非临时存储 . 将该限制设置为8GiB（或仅大于1 GiB缓冲区）以避免非临时存储在我的情况下性能翻倍（时间低至176毫秒） . 当然，那只与前向天真的表现相匹配，所以它并不是一流的 .这些系统上的BIOS允许启用/禁用四个不同的硬件预取程序（MLC Streamer Prefetcher，MLC Spatial Prefetcher，DCU Streamer Prefetcher和DCU IP Prefetcher） . 我尝试禁用每个，但这样做最好保持性能奇偶校验并降低一些设置的性能 .
禁用运行平均功率限制（RAPL）DRAM模式没有影响 .
我可以访问运行Fedora 19（glibc 2.17）的其他Supermicro系统 . 使用Supermicro X9DRG-HF板，Fedora 19和Xeon E5-2670 CPU，我看到与上面类似的性能 . 在运行Xeon E3-1275 v3（Haswell）和Fedora 19的Supermicro X10SLM-F单插槽板上，我看到_9904924_（104ms）的9.6 GB / s . Haswell系统的RAM是DDR3-1600（与其他系统相同） .
UPDATES
我将CPU电源管理设置为Max Performance并禁用BIOS中的超线程 . 根据
/proc/cpuinfo，核心的时钟频率为3 GHz . 然而，这奇怪地将内存性能降低了大约10％ .memtest86 4.10报告主内存的带宽为9091 MB / s . 我找不到这是否与读，写或复制相对应 .
STREAM benchmark报告13422 MB / s用于复制，但它们计算读取和写入的字节数，因此如果我们想要与上述结果进行比较，则相当于~6.5 GB / s .
这看起来很正常 .
管理带有两个CPU的8x16GB ECC记忆棒比使用2x2GB的单个CPU要困难得多 . 你的16GB硬盘是双面内存，它们可能有缓冲区ECC（甚至在主板级别禁用）......所有这些都使数据路径更长 . 你也有2个CPU共享ram，即使你在另一个CPU上什么也不做，总是很少有内存访问 . 切换此数据需要一些额外的时间 . 只要看看与显卡共享一些内存的PC上的巨大性能损失 .
你的服务器仍然是非常强大的数据泵 . 我不确定在现实生活中的软件中经常复制1GB，但我确信你的128GB比任何硬盘都快，甚至是最好的SSD，这也是你可以充分利用服务器的地方 . 使用3GB进行相同的测试会使您的笔记本电脑着火 .
这看起来是基于商用硬件的架构如何比大型服务器更有效的完美示例 . 在这些大型服务器上花费的钱可以买多少台消费者PC？
谢谢你提出非常详细的问题 .
EDIT : （花了我很长时间才写下这个答案，我错过了图表部分 . ）
我认为问题在于数据的存储位置 . 你能比较一下这个：
测试一：分配两个500Mb ram的连续块并从一个复制到另一个（你已经完成的）
测试二：分配20个（或更多）500Mb内存块并从第一个到最后一个复制，所以它们彼此相距很远（即使你不能确定它们的实际位置） .
这样你就可以了看看内存控制器如何处理远离彼此的内存块 . 我认为你的数据放在不同的内存区域，它需要在数据路径上的某个点进行切换操作，以便与一个区域进行通信，然后是另一个区域（双面内存存在这样的问题） .
另外，您确定线程绑定到一个CPU吗？
EDIT 2:
内存有几种“区域”分隔符 . NUMA是一个，但这不是唯一的 . 例如，双面支撑杆需要标记来指向一侧或另一侧 . 在图表中查看即使在笔记本电脑上（没有NUMA），性能也会因大块内存而降低 . 我不确定这一点，但是memcpy可能会使用硬件功能来复制ram（一种DMA），而且这个芯片的缓存必须比你的CPU少，这可以解释为什么带CPU的哑副本比memcpy快 .
基于IvyBridge的笔记本电脑中的某些CPU改进可能会比基于SandyBridge的服务器有所提升 .
Page-crossing Prefetch - 每当您到达当前的一个线性页面时，您的笔记本电脑CPU都会预先获取下一个线性页面，每次都会为您节省一个令人讨厌的TLB错过 . 要尝试缓解这种情况，请尝试为2M / 1G页面构建服务器代码 .
缓存替换方案似乎也得到了改进（参见一个有趣的逆向工程here） . 如果这个CPU确实使用了动态插入策略，那么它很容易阻止你复制的数据试图破坏你的Last-Level-Cache（由于它的大小无法有效地使用它），并为其他有用的缓存节省空间像代码，堆栈，页表数据等 . ） . 为了测试这个，您可以尝试使用流加载/存储重建您的天真实现（
movntdq或类似的，您也可以使用gcc builtin） . 这种可能性可以解释大数据集大小的突然下降 .我相信对字符串复制也做了一些改进（here），这里可能适用也可能不适用，具体取决于汇编代码的样子 . 您可以尝试使用Dhrystone进行基准测试，以测试是否存在固有差异 . 这也可以解释memcpy和memmove之间的区别 .
如果您能够获得基于IvyBridge的服务器或Sandy-Bridge笔记本电脑，最简单的方法是将所有这些一起测试 .
我修改了基准测试以在Linux中使用nsec计时器，并在不同处理器上发现了类似的变体，所有处理器都具有相似的内存所有正在运行的RHEL 6.数字在多次运行中保持一致 .
以下是内联C代码-O3的结果
对于它，我也尝试使内联memcpy一次做8个字节 . 在这些英特尔处理器上，它没有明显的区别 . Cache将所有字节操作合并到最小数量的内存操作中 . 我怀疑gcc库代码试图太聪明了 .
这个问题已经回答above，但无论如何，这是一个使用AVX的实现，对于大型副本应该更快，如果这是你担心的：
这些数字对我来说很有意义 . 这里实际上有两个问题，我会回答它们 .
首先，我们需要有一个关于大型内存传输如何在现代英特尔处理器上工作的心理模型 . 这种描述是近似的，细节可能会从架构到架构有所改变，但高层次的想法是相当不变的 .
当
L1数据高速缓存中的加载未命中时，将分配行缓冲区，该行缓冲区将跟踪未命中请求，直到它被填满 . 如果它在L2缓存中命中，则可能是短时间（十几个周期左右），如果它一直错过DRAM，则可能长得多（100纳秒） .每个core1的这些行缓冲区数量有限，一旦它们已满，进一步的未命中将停止等待一个 .
除了用于demand3加载/存储的这些填充缓冲区之外，还有用于DRAM和L2之间的内存移动的额外缓冲区以及预取所使用的低级缓存 .
内存子系统本身具有最大带宽限制，您可以在ARK上方便地找到它 . 例如，联想笔记本电脑中的3720QM显示限制为25.6 GB . 此限制基本上是有效频率（
1600 Mhz）乘以每次传输的8字节（64位）乘以通道数（2）的乘积：1600 * 8 * 2 = 25.6 GB/s. 手上的服务器芯片的峰值带宽为51.2 GB/s，每个插槽，用于总系统带宽约为102 GB / s .与其他处理器功能不同，在各种芯片中通常只有可能的理论带宽数，因为它仅取决于许多不同芯片，甚至跨架构的注释值 . 不切实际地期望DRAM以理论速率完全交付（由于各种低级别问题，讨论了一点here），但通常可以达到90％左右或更多 .
因此（1）的主要结果是你可以将RAM作为一种请求响应系统处理 . DRAM未命中分配填充缓冲区，并在请求返回时释放缓冲区 . 每个CPU只有10个这样的缓冲区用于需求未命中，这使得单个CPU可以生成的需求内存带宽与其延迟相关 .
例如，假设您的
E5-2680的DRAM延迟为80ns . 每个请求都会带来一个64字节的高速缓存行，所以你只是按顺序向DRAM发出请求，你希望吞吐量微不足道64 bytes / 80 ns = 0.8 GB/s，你再次将它减少一半（至少）以获得memcpy数字，因为它需要阅读和写作 . 幸运的是，您可以使用10个行填充缓冲区，这样您就可以将10个并发请求重叠到内存中，并将带宽增加10倍，从而使理论带宽达到8 GB / s .如果你想深入了解更多细节，this thread几乎是纯金 . 您会发现John McCalpin, aka "Dr Bandwidth中的事实和数据将成为下面的共同主题 .
那么让我们进入细节并回答两个问题......
为什么memcpy比服务器上的memmove或hand rolled copy慢得多？
你表明你的笔记本电脑系统在 120 ms 中执行了
memcpy基准测试，而服务器部件则需要 300 ms . 你还表明，这种缓慢主要不是根本性的，因为你能够使用memmove和你的手卷memcpy（以下称为hrm）来实现大约 160 ms 的时间，比笔记本电脑性能更接近（但仍然慢） .我们已经在上面表明，对于单核，带宽受到总可用并发和延迟的限制，而不是DRAM带宽 . 我们希望服务器部件的延迟时间更长，但不会更长！
答案在于 streaming (aka non-temporal) stores . 您正在使用的
memcpy的libc版本使用它们，但memmove没有 . 你确认了"naive"memcpy也没有使用它们，以及我配置asmlib既使用流媒体存储（慢速）而不是（快速） .流媒体商店损害了单个CPU数量，因为：
(A) 它们阻止预取将待存储的行引入缓存，这允许更多的并发性，因为预取硬件具有超过10个填充缓冲区的其他专用缓冲区，这些缓冲区需要加载/存储使用 .
(B) 已知E5-2680为流媒体商店particularly slow .
在上面的链接线程中，John McCalpin的引用更好地解释了这两个问题 . 关于预取有效性和流媒体商店的话题he says：
...然后，对于E5上流媒体商店显然更长的延迟，he says：
特别是，麦卡尔平博士测量的E5与使用"client"非核心的芯片相比减少了约1.8倍，但OP报告的2.5倍减速与此相同，因为STREAM TRIAD报告了1.8倍的分数：1个负载比率：商店，而
memcpy是1：1，商店是有问题的部分 .这个不会使流式传输成为一件坏事 - 实际上，您需要通过延迟来减少总带宽消耗 . 您获得的带宽较少，因为在使用单核时您的并发性受限，但是您可以避免所有读取所有权流量，因此如果您在所有核心上同时运行测试，您可能会看到（小）优势 .
到目前为止，作为您的软件或硬件配置的工件，其他用户使用相同的CPU报告了完全相同的减速 .
为什么使用普通商店时服务器部分仍然较慢？
即使在纠正非临时存储问题之后，您仍然会看到服务器部件大致减速 . 是什么赋予了？
好吧_2904974不是真的 - 你在服务器部件上支付的费用（通常是每片2000美元左右）主要是（a）更多核心（b）更多内存通道（c）支持更多总RAM（d）支持ECC，虚拟化功能等"enterprise-ish"功能 .
事实上，延迟方面，服务器部件通常只与客户端4部件相同或更慢 . 在内存延迟方面，尤其如此，因为：
服务器部件具有更高的可扩展性，但复杂的"uncore"通常需要支持更多的内核，因此RAM的路径更长 .
服务器部件支持更多RAM（100或GB或几TB），这通常需要electrical buffers来支持如此大的数量 .
与OP的情况一样，服务器部件通常是多插槽的，这会在内存路径中增加交叉插槽一致性问题 .
因此，服务器部件的延迟通常比客户端部件长40％到60％ . 对于E5，您可能会发现~80 ns是一个typical latency到RAM，而客户端部分接近50 ns .
所以RAM延迟受限的任何东西都会在服务器部件上运行得更慢，事实证明，单核上的
memcpy是延迟受限的 . 那令人困惑，因为memcpy似乎是带宽测量，对吧？如上所述，单个内核没有足够的资源来一次保留足够的RAM请求以接近RAM带宽6，因此性能直接取决于延迟 .另一方面，客户端芯片具有较低的延迟和较低的带宽，因此一个核心更接近于使带宽饱和（这通常是为什么流媒体存储在客户端部件上的巨大胜利 - 即使单个核心也可以接近RAM带宽，流存储提供的50％存储带宽减少有很大帮助 .
参考文献
有很多很好的资源来阅读这些东西，这里有几个 .
A detailed description of memory latency components
跨越新老CPU的
Lots of memory latency results（参见
MemLatX86和NewMemLat）链接Detailed analysis of Sandy Bridge (and Opteron) memory latencies - 几乎与OP使用的芯片相同 .
1大，我的意思是比LLC大一些 . 对于适合LLC（或任何更高的缓存级别）的副本，行为是非常不同的 . OPs
llcachebench图表显示，实际上性能偏差仅在缓冲区开始超过LLC大小时开始 .2特别是，行填充缓冲区的数量已有几代apparently been constant at 10，包括此问题中提到的体系结构 .
3当我们在这里说需求时，我们的意思是它与代码中的显式加载/存储相关联，而不是说通过预取引入 .
4当我在这里引用服务器部分时，我指的是一个带有服务器非核心的CPU . 这在很大程度上意味着E5系列，因为E3系列通常是uses the client uncore .
5将来，看起来您可以将"instruction set extensions"添加到此列表中，因为似乎
AVX-512将仅出现在Skylake服务器部件上 .在延迟为80 ns的情况下，我们需要始终在飞行中使用
(51.2 B/ns * 80 ns) == 4096 bytes或64个缓存线来达到最大带宽，但是一个核心提供的带宽少于20个 .根据英特尔ARK，E5-2650和E5-2680都有AVX扩展 .
这是你问题的一部分 . CMake为你选择一些相当差的旗帜 . 您可以通过运行
make VERBOSE=1来确认它 .您应该将
-march=native和-O3添加到CFLAGS和CXXFLAGS. 您可能会看到性能的显着提高 . 它应该参与AVX扩展 . 如果没有-march=XXX，您可以有效地获得最小的i686或x86_64机器 . 如果没有-O3，则不要进行't engage GCC'的矢量化 .我不是确定GCC 4.6是否能够AVX（以及朋友，如BMI） . 我知道GCC 4.8或4.9是有能力的，因为当GCC将memcpy和memset外包给MMX单元时，我不得不寻找导致段错误的对齐错误 . AVX和AVX2允许CPU一次操作16字节和32字节数据块 .
如果GCC错失了将对齐数据发送到MMX单元的机会，则可能会错过数据对齐的事实 . 如果您的数据是16字节对齐的，那么您可以尝试告诉GCC，以便它知道对胖块进行操作 . 为此，请参阅GCC的__builtin_assume_aligned . 另请参阅How to tell GCC that a pointer argument is always double-word-aligned?等问题
由于
void*，这看起来也有点怀疑 . 它抛弃了关于指针的信息 . 您应该保留以下信息：可能类似于以下内容：
另一个建议是使用
new，并停止使用malloc. 它的C程序和海湾合作委员会可以对new做一些关于malloc无法做出的假设 . 我相信GCC的内置插件选项页面中详细介绍了一些假设 .另一个建议是使用堆 . 它在典型的现代系统上始终是16字节对齐的 . GCC应该认识到，当涉及到来自堆的指针时，它可以卸载到MMX单元（没有潜在的
void*和malloc问题） .最后，有一段时间，Clang在使用
-march=native时没有使用本机CPU扩展 . 例如，参见Ubuntu Issue 1616723, Clang 3.4 only advertises SSE2，Ubuntu Issue 1616723, Clang 3.5 only advertises SSE2和Ubuntu Issue 1616723, Clang 3.6 only advertises SSE2 .