根据实际硬件不同，也有可能这个是最佳的。

如果瓶颈在ddr ram上，比如极端情况用DDR-400搭配主频很高的cpu，那四次*s++=*d++和一次movq很可能是一样快的。movq可以空出一些流水线给超线程用。至于是否用得上那也不保证。反正单线程benchmark很可能看上去差不多。

intel的cpu对我们程序员来说是个黑盒子。厂家不会公开说它是怎么优化的。没准它的decoder认识连续四条*s++=*d++，会自动翻译成和movq一样的微码。这是完全可以做到，而且很可能已经做了的。唯一确保最佳性能的办法就是做实验测，摸清每个指令的延迟多少，对流水线的影响多大，对cache的影响多大。。。慢慢把黑盒的内部结构给逆向工程出来。（做JIT编译器的人主要就是做这些工作）

我见过有一个网站专门测试并公开这些数据的，回头收藏夹里看看，如果能找到就贴上来给你们。

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这个不可能是最佳实现。。在现代处理器上面，单字节访问非常慢。
: 你发的这种实现无非是朴素实现的简单推广：
: 1. 没考虑内存地址对齐
: 2. 至少用个戴夫设备吧。
: 3. 用 simd 指令集一次复制 32 字节才是王道啊。
: edit: 有内存地址对齐。
--
FROM 114.84.111.*

楼主贴这段，字节对齐的，否则它搞一堆位运算是为什么。
glibc兜底的平台无关memcpy差不多也长这样。

【 在 lushan5436 的大作中提到: 】
: ARM指令，字节不对齐，转int会报错，你不考虑？
: 就算是X86，windows的实现（比早年linux实现好多了）也考虑比这多，不信你调试时去看汇编。
: 没有说不如我：我说的是，如果写C程序，怎么不可能考虑字节对齐的问题？怎么可能还不知道sse2加速？
: ...................
--
修改:ilovecpp FROM 124.78.168.*
FROM 124.78.168.*

神童啊，除了跪拜无话可说。
【 在 lvsoft 的大作中提到: 】
: 嗯，达到了我高一时候的水平
--
FROM 106.39.149.*

中间隔着cache呢，哪能这么比。
这种通用实现也不追求最优。具体平台上用movsq乃至avx512的实现都有。

【 在 javaboy 的大作中提到: 】
: 根据实际硬件不同，也有可能这个是最佳的。
: 如果瓶颈在ddr ram上，比如极端情况用DDR-400搭配主频很高的cpu，那四次*s++=*d++和一次movq很可能是一样快的。movq可以空出一些流水线给超线程用。至于是否用得上那也不保证。反正单线程benchmark很可能看上去差不多。
: intel的cpu对我们程序员来说是个黑盒子。厂家不会公开说它是怎么优化的。没准它的decoder认识连续四条*s++=*d++，会自动翻译成和movq一样的微码。这是完全可以做到，而且很可能已经做了的。唯一确保最佳性能的办法就是做实验测，摸清每个指令的延迟多少，对流水线的影响多大，对cache的影响多大。。。慢慢把黑盒的内部结构给逆向工程出来。（做JIT编译器的人主要就是做这些工作）
: ...................
--
FROM 124.78.168.*

我觉得就是你总结的：glibc兜底的平台无关memcpy差不多也长这样

然后前面wushu查了说这是musl的代码。

从编程、汇编角度来说这样就可以结贴啦。再往下挖要不就聊聊总线协议和dma呗。

【 在 ilovecpp (cpp) 的大作中提到: 】
: 中间隔着cache呢，哪能这么比。
: 这种通用实现也不追求最优。具体平台上用movsq乃至avx512的实现都有。
--
FROM 114.84.111.*