- 主题:64 位计算机，内存地址对齐四字节还是八字节比较有效率？
很荣幸 @philbloo 能将我看做朋友，自从上次共同认为通过晶体管翻转次数来鉴定代码好坏是一个方法，
就感觉碰到同路人，这钟思维上天马行空的讨论，是我们技术人员特有的快乐，有空我们再聊
至于支付宝的数据库开发结果说一下状态，现在这套原创数据库（c和汇编）已经上线并处理每一笔支付宝的交易，
我们的技术要在支付宝核心账务部门落地是需要可观的数据成果和严苛的验证,
最终才能解决热点账户这样的行业问题。
因为涉及到公司的机密，我不可能与每个问我的人细聊
【 在 philbloo 的大作中提到: 】
: 我是maling的朋友 leadu硬生生踩maling一脚 我给他踩回去
:
【 在 philbloo 的大作中提到: 】
: 我是maling的朋友 leadu硬生生踩maling一脚 我给他踩回去
:
--
修改:MaLing FROM 106.3.229.*
FROM 140.210.153.*
1. 如果你认为的最好指的是cycle级别,那么对齐最好。是否对齐也跟你使用的指令有关，但是也许为了对齐会产生overhead大于对齐带来的好处
2. memcpy在系统中的延迟也来自于跳转预测失败，所以很多地方我采取覆盖写的方法减少跳转指令的使用，同时这种方法也解决了memory false dependence
3. 如果能不用还是尽量不用，除了跳转预测失败带来的问题，数据迁移也会污染数据和指令
【 在 hgoldfish 的大作中提到: 】
: 假定要执行 memcpy(*dest, *src, n) 复制一段内存。正常在 amd64 计算机下，dest, src 两个指针最好是对齐的。
: 那么，不同的计算机架构会要求不同的对齐方式吗？还是说只要对齐到 4 个字节就行？
--
修改:MaLing FROM 116.30.17.*
FROM 140.210.153.*
这个也要看pipeline 的load/store到L1 cache的data path 的width，还需要结合cpu到bus的接口width。最好访问的数据不要低于这个位宽的data length。这些细节感觉目前不重要了。
现在不是有memcpy的指令吗。arm 上也有了。
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 也就是说 memcpy() 已经考虑了不对齐的情况，所以程序员不需要特别的优化。但是操作内存的时候，为了让 load/store 更加高效，应该尽量按计算机的字对齐是吧？64 位计算机就对齐到 8 个字节是最好的？
:
: 【 在 ArchLinux 的大作中提到: 】
: : 一般来说是优化load吧，就是把source对齐，因为程序的延迟来源于load，
--
FROM 114.85.234.*
我来认认真真的解释一下，MaLing 说的某些是对的。
首先，在Intel CPU上，对于memcpy这样的操作，假设你的内存带宽不是瓶颈（这个假设恐怕不成立），那么最佳方式就是利用CPU的SIMD来实现这样的操作。那么很显然SIMD是对对齐有要求的。即便只考虑Intel CPU，你也得想到底是SSE还是AVX还是AVX2还是AVX512。 不同指令集扩展对此要求不一样。比如AVX512需要64字节对齐。512 bits are 64 bytes.
但是你的input 数组的长度未必恰好是64字节的整数倍。所以这时候就需要多写一些if...else去处理剩余的不够64字节的部分。如果你追求极致，这些代码会影响程序效率。一个简化做法就是多分配一些，要求所有这样的buffer都是按64字节对齐并且长度是64的整数倍。
【 在 hgoldfish 的大作中提到: 】
: 假定要执行 memcpy(*dest, *src, n) 复制一段内存。正常在 amd64 计算机下，dest, src 两个指针最好是对齐的。
: 那么，不同的计算机架构会要求不同的对齐方式吗？还是说只要对齐到 4 个字节就行？
--
FROM 107.139.34.*
这个说法是最合理的 影响内存访问的因素太多 必须具体问题具体分析
比方说矩阵乘法和SHA3混合使用的情况，里面是load/store到多个 sram bank。有不止一个 bus master 在工作，除了 cpu 之外还有 hash coprocessor ，dma，modulo arithmetic coprocessor。bus 可能有不止一个，还得考虑 instruction 和 data 抢 bus，以及 cache 大小等等等等。找到最少 contention 的唯一的办法是细粒度的测试加上 heuristic 调整，根据不同的硬件做不同的调试，而且即使这样也只能宣称 near optimal 。
所以想毕其功于一役的找到唯一一个最佳 memcpy 是缘木求鱼。
【 在 MaLing 的大作中提到: 】
:
https://sourceware.org/legacy-ml/libc-alpha/2015-01/msg00651.html: 这是OndAej 对于dpdk memcpy的评价
:
--
FROM 176.93.89.*
很赞同你说的关于矩阵乘法这一段。
--
FROM 107.139.34.*
【 在 philbloo 的大作中提到: 】
: 这个说法是最合理的 影响内存访问的因素太多 必须具体问题具体分析
: 比方说矩阵乘法和SHA3混合使用的情况，里面是load/store到多个 sram bank。有不止一个 bus master 在工作，除了 cpu 之外还有 hash coprocessor ，dma，modulo arithmetic coprocessor。bus 可能有不止一个，还得考虑 instruction 和 data 抢 bus，以及 cache 大小等等等等。找到最少 contention 的唯一的办法是细粒度的测试加上 heuristic 调整，根据不同的硬件做不同的调试，而且即使这样也只能宣称 near optimal 。
: 所以想毕其功于一役的找到唯一一个最佳 memcpy 是缘木求鱼。
: ...................
对硬件新的优化策略和实现关注的不多，
目前， 如果数据在内存和GPU内存直接的move的话， 这个是个什么流程？
也是需要借助CPU寄存器通过特定指令完成吗？
这个PCIE总线属于外设模式了， 是不是通过IO指令完成？
--
FROM 124.126.0.*
其实最新的cpu在这块区别不大了，虽然指令上有对齐和不对齐两个指令，但在微指令上好像性能差别不大了（没有亲自测试过，也是听别人分享的测试结果）
【 在 snnn (cm) 的大作中提到: 】
: 我来认认真真的解释一下，MaLing 说的某些是对的。
: 首先，在Intel CPU上，对于memcpy这样的操作，假设你的内存带宽不是瓶颈（这个假设恐怕不成立），那么最佳方式就是利用CPU的SIMD来实现这样的操作。那么很显然SIMD是对对齐有要求的。即便只考虑Intel CPU，你也得想到底是SSE还是AVX还是AVX2还是AVX512。 不同指令集扩展对此要求不一样。比如AVX512需要64字节对齐。512 bits are 64 bytes.
:
: 但是你的input 数组的长度未必恰好是64字节的整数倍。所以这时候就需要多写一些if...else去处理剩余的不够64字节的部分。如果你追求极致，这些代码会影响程序效率。一个简化做法就是多分配一些，要求所有这样的buffer都是按64字节对齐并且长度是64的整数倍。
--
FROM 183.213.128.*