帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:35&分页:tianbing发信人: tianbing1212 (tianbing), 信区: CSArch
标&&题: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Mon Aug 31 22:10:22 2015), 站内 && （应@mcx之约，对本贴爬楼，整理如下）&& 【问题的提出】&& 同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统要快？如果是，原理是什么？&&
假定CPU是一个型号，内存均为4G，都是linux系统。&&&&&& 【考虑的因素】&& “64位”系统的不同含义对性能产生了不同的影响&& 1，寄存器数量&& 有的体系结构，比如x86,64位比32位多几个寄存器，对性能有积极作用&& n32 n64出现的原因是有个蛋疼的人觉得大多数应用程序在多两个寄存器传参的时候性能会好一些，所以，叫new abi，后来有人发现32位的new abi在code size和性能方面比64&&
位new abi好，当然，这只是无心之失罢了。&&
说不好性能上谁好谁差，毕竟现实世界的程序不是benchmark，随便造点儿看上去很美的数据就发看上去很牛逼的paper了。&& &&&& 2，内存大小（架构寻址空间）&& 64程序使用的内存又比32位大，对性能有副作用。&& 当然要找 32 位比 64 位跑得快的也很容易，找用内存多的就行了&&&&&& 3，数据宽度&& 要找一个 64 位跑得比 32 位快的程序还是很容易的.. 大量 64 位整数运算，或者大量浮点运算，然后内存又用得不多的程序，快百分之几十也正常得很..&&&&&& 4，指令密度（代码尺寸，指针长度）&& 做 x32 的动机不复杂啊，H.J. Lu 他们帮过一个 presentation（），无非就是说 x86-64 比 ia32 好太多了，可惜很多情况下指针没必要是 64 位，所以他们想把 x86-64 和 ia32 的优点给集合在一起&&&& 按维基百科的说法，这种 ABI 在 2003 年 AMD64 刚发布的时候就有人提过了，后来 Knuth 老爷子又在 2008 年呼吁了一下&&&& benchmark 结果在 x32 的主页上就有： &&&& 比 x86-64 快的那部分基本上就可以认为是指针大小的改变带来的，比 32 位快的那部分基本上就可以认为是寄存器带来的（增多、变长、传参、RIP-relative addressing）&&
（当然 x32 网站上的 benchmark 也不是很客观，选择性地取了对 x32 最有利的数据）&&
假定两个系统都是4G，我的方法是比较指令密度（平均每条执行的代码长度下包含的有效操作数），相同的workload指令密度越大越好。&& 补充一句：经过ms-rom的那些指令除外，他们不应该算是一条指令。&& 如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&&
很明显能得到更多L1-I命中或者减少指令运行时间。&&
在x32之前intel compiler就有个选项叫-auto_ilp32。HJ会不清楚这东西的用途？会拍脑袋说我们做个x32？更早的64位unix系统基本都支持lp64和ilp32两种data mode，会没有人对比过这两种模式的优缺点？&&
如edx, rdx真实包含的内容为0x,两条指令自然等价，此时32位指令下指令密度更大，且会产生指令缓存更好的结果，若比较的数据是64位，32位指令需要比较两次当然64位指令密度大。&&&& &&&& 5，iCache大小&& icache miss最大的问题是不但自身阻碍流水线向前，由于instruction miss导致取数据&&
时候产生气泡，这样无法利用cache,memory的throughput latency,全部转换成access&&&& latency.因此必须及时修正。&&
如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&&
很明显能得到更多L1-I命中或者减少指令运行时间。&&
至于i-cache的问题，不同的workload有不同的反应，但是总体来说减少其Miss是对的。&& 指令cache对性能影响？&&
由于前端是in order所以一旦产生缺失，严重阻碍后面的代码，导致的latency大于dcache。&&
X32的性能提升也可以说由于其对应的32位指令的指令密度大于64位系统，&&
但是他们的性能提升却是来自于d-cache（429-mcf）。&&
如果是手工写的代码我们甚至引入了8位指令。&&
cavium 的core 内icache 已经达到 78KB, intel 虽然是32KB但是他有core内L2，&&
多核系统大量测试中icache miss 表现的非常严重。&& 对于networking应用，为了保证延迟小，对于不同的packet类型要能第一时间在l1 i$命中 handler&&
而且一般是control plane&&
这种处理器的dataplane是hardware engine做的，而且即使对于control plane的packet, 对d-cache也有优化，类似于io-coherency logic可以做到让packet header在l1 d-cache中，payload在L2这样，反而对d-cache要求并不是那么高。&&
OLTP, 当然还有我们的应用程序，都表现出对icache的问题。&&
至于你提到无法线性扩展，我们的结论是其制约于：应用程序&&& cache cohrenece & wire latency &总线带宽&内部互联架构 & 透明于OS的线程调度如 fine grain /coarse grain/smt & die size & 制程工艺，反倒与dcache关系很小。&&
x32的上面由于其指令密度大于完全的64位指令，比如movq edx, (%eax), movq rdx, (%rax) 明显前者指令密度更大，虽然icache此时不是瓶颈，指令密度大间接给dcache带来了好处。注：x32 这个结论是文章上说的，但是我到是感到由于L2&L3是unified cache,dcache使用变小 icache一定也会变好，难道性能的提升真的完全来自于dcache ???&&&& &&&& movl %edx, (%eax)&& movq %rdx,(%rax)&&&&
这两个一样吧，前面的要 67 前缀，后面的要 48 前缀&&&&
gcc -mx32 现在就大量生成 (%eax) 这样的寻址，即使能够推断出 %rax 的高 32 位是全 0。你们有空贡献点代码吧，这种情况下生成 (%rax) 就好了..&&&&
x32 下面 (%esp) 基本可以无条件替换成 (%rsp)，gcc 现在也没做&& &&&& Cavium Octeon在使用中的确碰到i$ miss带来的性能损失，而d$反而没有那么严重的问题。&&
d$即使有问题，也相对容易分析问题原因，并且解决，而i$则难的多。&&&&
我们的elf大概50M左右，根据profiling可以很明确的得出性能下降是i$造成的，但是一直没法解决这个问题。&&&& 后来根据这篇老论文[1]做了一些工作，i$ miss降低到了可接受范围，packet rate也上升到了可接受范围。&&
但这不是一个持久的解决方案，因为代码一直在增加，业务完全不相关部分的代码增加和修改都会导致关键路径上的i$增加（或者减少，基本靠蒙），而我们没法每次代码修改都做一次profiling-修改directed call graph，所以这个方案暂时搁置了。&&&& 不知道 @MaLing 有啥妙计可以共享？&&&&
是否可以考虑把不同的handler bind到不同的core上？&&
已经是这么做的了。当然粒度还比较粗，应该可以再做细一些。但是细也有个极限，总共就那么多core。&&
话说回来，似乎除此之外没有其它办法解决i$ miss了。&&
Pentium 4的trace cache这种机制没准能好一些，类似于存储程序的热路径，而不是简单的从地址去match&& &&&& 硬件能这么做，软件就没辙了&&&&
不过我倒是有个想法，不是那篇论文里说的那样把热路径上的routine给layout在一起，而是把热路径上的routine给layout在不同的cache line或者set里。而可以这么做的假设是，对于指定的一款processor，可以明确的知道virtual address到cache line的对应。&&&&
比如routineA和routineB是热路径上的两个routine，那么我们就得让routineA和routineB的set index不同或者tag不同。如果这款processor的virtual address里有几个低位bits是对应set index，那么就得让linker在layout的时候关照这两个routine。当然一般来说linker不知道运行时的virtual address，但可以以.text的起始位置为原点，算两个routine的相对地址，因为要比较的一般来说是低位，所以相对地址就够了。&&&&
当然，这得把逻辑写到linker里（或者是plugin），而且还是得以runtime profiling的结果来做参照。具体操作起来还是很麻烦。&& &&&&&&&& 6，数据cache大小&& x32相对于x64的性能提升是来自于Icache还是dcache？&&
dcache, 指针长度变少使用cache存储较少。&&
至少对speccpu rate来说，仍然是d$的因素导致无法线性扩展。&&
从编译器的角度看，d$导致的性能问题仍然是主流问题&&&&&& 7，综合&& 他们就是从代码密度去说的，同一个应用程序在64位和32位就是谁的代码密度大，谁的I-cache的miss率低，所以性能更好。前提是同一个程序比较的是I-CAHCE，D-CACHE的效率是相当的。&&
当然从general的角度来说，CPU性能的瓶颈在D-CACHE的命中率上不高，而在I-cache上其实已经很高了，所以认为D-CACHE是性能的瓶颈。&& &&&&&&&&&&&& 感谢下列id在此问题讨论上作出的杰出贡献&& @gdss @houge @vonNeumann @Aquamarine @MaLing @pxa255 @rockyzhang @philbloo @mcx&& -- && ※ 来源:·水木社区 ·[FROM: 211.100.31.*] && 有6位用户评价了这篇文章：[+5]erlv:赞深度技术文[+5]lemonniu1231:[+5]tuzi37:[+5]gooking:[+3]fanxingecho:[+5]forrestrun:tianbing发信人: tianbing1212 (tianbing), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Mon Aug 31 22:10:41 2015), 站内 && @mcx 已重发
【 在 tianbing1212 的大作中提到: 】
: （应@mcx之约，对本贴爬楼，整理如下）&&
: 同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统要快？如果是，原理是什么？&&
: 假定CPU是一个型号，内存均为4G，都是linux系统。&&
: ...................
&& -- && ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
娶柠檬妻发信人: mcx (娶柠檬妻), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 13:48:36 2015), 站内 && 不错哦，那先上这一篇吧，本版人气少一点，宠物版的那个帖子过几天再上。
【 在 tianbing1212 (tianbing) 的大作中提到: 】
: 标&&题: 64位系统是否比32位系统计算速度快
: 发信站: 水木社区 (Mon Aug 31 22:10:22 2015), 站内
: （应@mcx之约，对本贴爬楼，整理如下）&&
: 【问题的提出】&&
: 同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统要快？如果是，原理是什么？&&
: 假定CPU是一个型号，内存均为4G，都是linux系统。&&
: 【考虑的因素】&&
: “64位”系统的不同含义对性能产生了不同的影响&&
: 1，寄存器数量&&
: 有的体系结构，比如x86,64位比32位多几个寄存器，对性能有积极作用&&
: n32 n64出现的原因是有个蛋疼的人觉得大多数应用程序在多两个寄存器传参的时候性能会好一些，所以，叫new abi，后来有人发现32位的new abi在code size和性能方面比64&&
: 位new abi好，当然，这只是无心之失罢了。&&
: 说不好性能上谁好谁差，毕竟现实世界的程序不是benchmark，随便造点儿看上去很美的数据就发看上去很牛逼的paper了。&&
: 2，内存大小（架构寻址空间）&&
: 64程序使用的内存又比32位大，对性能有副作用。&&
: 当然要找 32 位比 64 位跑得快的也很容易，找用内存多的就行了&&
: 3，数据宽度&&
: 要找一个 64 位跑得比 32 位快的程序还是很容易的.. 大量 64 位整数运算，或者大量浮点运算，然后内存又用得不多的程序，快百分之几十也正常得很..&&
: 4，指令密度（代码尺寸，指针长度）&&
: 做 x32 的动机不复杂啊，H.J. Lu 他们帮过一个 presentation（），无非就是说 x86-64 比 ia32 好太多了，可惜很多情况下指针没必要是 64 位，所以他们想把 x86-64 和 ia32 的优点给集合在一起&&&&
: 按维基百科的说法，这种 ABI 在 2003 年 AMD64 刚发布的时候就有人提过了，后来 Knuth 老爷子又在 2008 年呼吁了一下&&&&
: benchmark 结果在 x32 的主页上就有： &&&&
: 比 x86-64 快的那部分基本上就可以认为是指针大小的改变带来的，比 32 位快的那部分基本上就可以认为是寄存器带来的（增多、变长、传参、RIP-relative addressing）&&
: （当然 x32 网站上的 benchmark 也不是很客观，选择性地取了对 x32 最有利的数据）&&
: 假定两个系统都是4G，我的方法是比较指令密度（平均每条执行的代码长度下包含的有效操作数），相同的workload指令密度越大越好。&&
: 补充一句：经过ms-rom的那些指令除外，他们不应该算是一条指令。&&
: 如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&&
: 很明显能得到更多L1-I命中或者减少指令运行时间。&&
: 在x32之前intel compiler就有个选项叫-auto_ilp32。HJ会不清楚这东西的用途？会拍脑袋说我们做个x32？更早的64位unix系统基本都支持lp64和ilp32两种data mode，会没有人对比过这两种模式的优缺点？&&
: 如edx, rdx真实包含的内容为0x,两条指令自然等价，此时32位指令下指令密度更大，且会产生指令缓存更好的结果，若比较的数据是64位，32位指令需要比较两次当然64位指令密度大。&&&&
: 5，iCache大小&&
: icache miss最大的问题是不但自身阻碍流水线向前，由于instruction miss导致取数据&&
: 时候产生气泡，这样无法利用cache,memory的throughput latency,全部转换成access&&&&
: latency.因此必须及时修正。&&
: 如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&&
: 很明显能得到更多L1-I命中或者减少指令运行时间。&&
: 至于i-cache的问题，不同的workload有不同的反应，但是总体来说减少其Miss是对的。&&
: 指令cache对性能影响？&&
: 由于前端是in order所以一旦产生缺失，严重阻碍后面的代码，导致的latency大于dcache。&&
: X32的性能提升也可以说由于其对应的32位指令的指令密度大于64位系统，&&
: 但是他们的性能提升却是来自于d-cache（429-mcf）。&&
: 如果是手工写的代码我们甚至引入了8位指令。&&
: cavium 的core 内icache 已经达到 78KB, intel 虽然是32KB但是他有core内L2，&&
: 多核系统大量测试中icache miss 表现的非常严重。&&
: 对于networking应用，为了保证延迟小，对于不同的packet类型要能第一时间在l1 i$命中 handler&&
: 而且一般是control plane&&
: 这种处理器的dataplane是hardware engine做的，而且即使对于control plane的packet, 对d-cache也有优化，类似于io-coherency logic可以做到让packet header在l1 d-cache中，payload在L2这样，反而对d-cache要求并不是那么高。&&
: OLTP, 当然还有我们的应用程序，都表现出对icache的问题。&&
: 至于你提到无法线性扩展，我们的结论是其制约于：应用程序&&& cache cohrenece & wire latency &总线带宽&内部互联架构 & 透明于OS的线程调度如 fine grain /coarse grain/smt & die size & 制程工艺，反倒与dcache关系很小。&&
: x32的上面由于其指令密度大于完全的64位指令，比如movq edx, (%eax), movq rdx, (%rax) 明显前者指令密度更大，虽然icache此时不是瓶颈，指令密度大间接给dcache带来了好处。注：x32 这个结论是文章上说的，但是我到是感到由于L2&L3是unified cache,dcache使用变小 icache一定也会变好，难道性能的提升真的完全来自于dcache ???&&&&
: movl %edx, (%eax)&& movq %rdx,(%rax)&&&&
: 这两个一样吧，前面的要 67 前缀，后面的要 48 前缀&&&&
: gcc -mx32 现在就大量生成 (%eax) 这样的寻址，即使能够推断出 %rax 的高 32 位是全 0。你们有空贡献点代码吧，这种情况下生成 (%rax) 就好了..&&&&
: x32 下面 (%esp) 基本可以无条件替换成 (%rsp)，gcc 现在也没做&&
: Cavium Octeon在使用中的确碰到i$ miss带来的性能损失，而d$反而没有那么严重的问题。&&
: d$即使有问题，也相对容易分析问题原因，并且解决，而i$则难的多。&&&&
: 我们的elf大概50M左右，根据profiling可以很明确的得出性能下降是i$造成的，但是一直没法解决这个问题。&&&&
: 后来根据这篇老论文[1]做了一些工作，i$ miss降低到了可接受范围，packet rate也上升到了可接受范围。&&
: 但这不是一个持久的解决方案，因为代码一直在增加，业务完全不相关部分的代码增加和修改都会导致关键路径上的i$增加（或者减少，基本靠蒙），而我们没法每次代码修改都做一次profiling-修改directed call graph，所以这个方案暂时搁置了。&&&&
: 不知道 @MaLing 有啥妙计可以共享？&&&&
: 是否可以考虑把不同的handler bind到不同的core上？&&
: 已经是这么做的了。当然粒度还比较粗，应该可以再做细一些。但是细也有个极限，总共就那么多core。&&
: 话说回来，似乎除此之外没有其它办法解决i$ miss了。&&
: Pentium 4的trace cache这种机制没准能好一些，类似于存储程序的热路径，而不是简单的从地址去match&&
: 硬件能这么做，软件就没辙了&&&&
: 不过我倒是有个想法，不是那篇论文里说的那样把热路径上的routine给layout在一起，而是把热路径上的routine给layout在不同的cache line或者set里。而可以这么做的假设是，对于指定的一款processor，可以明确的知道virtual address到cache line的对应。&&&&
: 比如routineA和routineB是热路径上的两个routine，那么我们就得让routineA和routineB的set index不同或者tag不同。如果这款processor的virtual address里有几个低位bits是对应set index，那么就得让linker在layout的时候关照这两个routine。当然一般来说linker不知道运行时的virtual address，但可以以.text的起始位置为原点，算两个routine的相对地址，因为要比较的一般来说是低位，所以相对地址就够了。&&&&
: 当然，这得把逻辑写到linker里（或者是plugin），而且还是得以runtime profiling的结果来做参照。具体操作起来还是很麻烦。&&
: 6，数据cache大小&&
: x32相对于x64的性能提升是来自于Icache还是dcache？&&
: dcache, 指针长度变少使用cache存储较少。&&
: 至少对speccpu rate来说，仍然是d$的因素导致无法线性扩展。&&
: 从编译器的角度看，d$导致的性能问题仍然是主流问题&&
: 7，综合&&
: 他们就是从代码密度去说的，同一个应用程序在64位和32位就是谁的代码密度大，谁的I-cache的miss率低，所以性能更好。前提是同一个程序比较的是I-CAHCE，D-CACHE的效率是相当的。&&
: 当然从general的角度来说，CPU性能的瓶颈在D-CACHE的命中率上不高，而在I-cache上其实已经很高了，所以认为D-CACHE是性能的瓶颈。&&
: 感谢下列id在此问题讨论上作出的杰出贡献&&
: @gdss @houge @vonNeumann @Aquamarine @MaLing @pxa255 @rockyzhang @philbloo @mcx&&
: ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
:&& &&&& --
一袭尘，多少红颜春风的笑。
一片月，万千征人如霜的情。
一汪水，些许女子幽幽的怨。
一爿屋，那个人儿眷眷的心。 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 210.76.108.*]
你大爷永远都是你大爷发信人: Aquamarine (你大爷永远都是你大爷), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 16:37:58 2015), 站内 && 能不能结合指针长度对大文件IO和小文件IO分析一下啊？啥cake的，对性能的影响根本不
如IO明显啊！！！ && 【 在 tianbing1212 (tianbing) 的大作中提到: 】
: （应@mcx之约，对本贴爬楼，整理如下）&&
: 同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统
要快？如果是，原理是什么？&&
: 假定CPU是一个型号，内存均为4G，都是linux系统。&&
: ...................
&& -- && ※ 来源:·水木社区 ·[FROM: 118.187.12.*]
立体发信人: xyz3d (立体), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 17:24:06 2015), 站内 && 觉得这么空泛的谈cpu快慢。。。那外设 总线 一概不要考虑了。。。
用文件io来说快慢也感觉文不对题，是不还是要用偏计算性的benchmark啊 && @Aquamarine
【 在 Aquamarine (你大爷永远都是你大爷) 的大作中提到: 】
: 能不能结合指针长度对大文件IO和小文件IO分析一下啊？啥cake的，对性能的影响根
: 如IO明显啊！！！
: 要快？如果是，原理是什么？&&
&& -- && ※ 修改:·xyz3d 于 Sep&&1 17:24:39 2015 修改本文·[FROM: 192.100.120.*]
※ 来源:·水木社区 ·[FROM: 192.100.120.*]
哲良发信人: Buntu (哲良), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 18:45:52 2015), 站内 && re
【 在 tianbing1212 的大作中提到: 】
: （应@mcx之约，对本贴爬楼，整理如下）&&
: 同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统要快？如果是，原理是什么？&&
: 假定CPU是一个型号，内存均为4G，都是linux系统。&&
: ...................
&& -- && ※ 来源:·水木社区 ·[FROM: 115.231.92.*]
bdsf发信人: torcher (bdsf), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 19:00:46 2015), 站内 && g d s
-- && ※ 来源:·水木社区 ·[FROM: 125.39.145.*]
tianbing发信人: tianbing1212 (tianbing), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 19:02:11 2015), 站内 && 啥意思？
【 在 torcher 的大作中提到: 】
&& -- && ※ 来源:·水木社区 ·[FROM: 111.204.49.*]
bdsf发信人: torcher (bdsf), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Tue Sep&&1 19:04:57 2015), 站内 && 高大上。哈哈。
你可以考你周围人一个很深奥的问题。
CPU的意思是中央处理器，那么请问CUP的意思是什么？
【 在 tianbing1212 的大作中提到: 】
: 啥意思？
&& -- && ※ 来源:·水木社区 ·[FROM: 125.39.145.*]
永不忘记发信人: ybwj (永不忘记), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Wed Sep&&2 08:57:35 2015), 站内 && 不明白第2条为什么几句话就完事， 这条最重要，
现在的应用程序越来越大，很轻松超过2-4个G,&&所以64位稳盈 && 当然楼主非要比谁 1+ 1谁运算快，我没得说 && --
※ 修改:·ybwj 于 Sep&&2 08:58:26 2015 修改本文·[FROM: 117.89.90.*]
※ 来源:·水木社区 ·[FROM: 117.89.90.*]
文章数:35&分页:帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:70&分页:乱娃发信人: garfunkle (乱娃), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sat Aug 15 20:58:57 2015), 站内 && 斑竹 明晰 && 【 在 tianbing1212 (tianbing) 的大作中提到: 】
: 有些好奇ls这9个月干啥去了
&&&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 121.34.146.*]
uranus发信人: MaLing (uranus), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sat Aug 15 21:58:32 2015), 站内 && ls 是什么意思？
【 在 tianbing1212 (tianbing) 的大作中提到: 】
: 有些好奇ls这9个月干啥去了
&& -- && ※ 来源:·水木社区 ·[FROM: 36.250.66.*]
tianbing发信人: tianbing1212 (tianbing), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sat Aug 15 22:07:16 2015), 站内 && l(ou) s(hang)
【 在 MaLing 的大作中提到: 】
: ls 是什么意思？
&& -- && ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
uranus发信人: MaLing (uranus), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sat Aug 15 22:11:26 2015), 站内 && 还是你洋气，
测试系统，找出计算特征，性能瓶颈，然后优化，有好点的再写专利，
大家都这样啊。
【 在 tianbing1212 (tianbing) 的大作中提到: 】
: l(ou) s(hang)
-- && ※ 来源:·水木社区 ·[FROM: 36.250.66.*]
tianbing发信人: tianbing1212 (tianbing), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sat Aug 15 22:17:26 2015), 站内 && 这里只提及了现象，没介绍手段啊？
还是曾经介绍过，又删了？
【 在 MaLing 的大作中提到: 】
: haswell 使用这个方法提升性能：
: 以用32bytes
: ...................
&& -- && ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
uranus发信人: MaLing (uranus), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sat Aug 15 22:41:19 2015), 站内 && 可以分析啊
【 在 tianbing1212 (tianbing) 的大作中提到: 】
: 这里只提及了现象，没介绍手段啊？
: 还是曾经介绍过，又删了？
&& -- && ※ 来源:·水木社区 ·[FROM: 36.250.66.*]
娶柠檬妻发信人: mcx (娶柠檬妻), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Wed Aug 19 14:31:35 2015), 站内 && 这个帖子多好啊，版主要不要辛苦爬一下楼，把大家的帖子整理成一个版面原创推荐一下？
【 在 tianbing1212 (tianbing) 的大作中提到: 】
: 标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
: 发信站: 水木社区 (Sat Aug 15 22:17:26 2015), 站内
: 这里只提及了现象，没介绍手段啊？
: 还是曾经介绍过，又删了？
: 【 在 MaLing 的大作中提到: 】
: : haswell 使用这个方法提升性能：
: : 以用32bytes
: : ...................
: ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
一袭尘，多少红颜春风的笑。
一片月，万千征人如霜的情。
一汪水，些许女子幽幽的怨。
一爿屋，那个人儿眷眷的心。 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 222.132.52.*]
tianbing发信人: tianbing1212 (tianbing), 信区: CSArch
标&&题: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Sun Aug 30 15:23:11 2015), 站内 &&&& （应@mcx之约，对本贴爬楼，整理如下）
【问题的提出】
同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统要快？如果是，原理是什么？&& 假定CPU是一个型号，内存均为4G，都是linux系统。 && 【考虑的因素】
“64位”系统的不同含义对性能产生了不同的影响
1，寄存器数量
有的体系结构，比如x86,64位比32位多几个寄存器，对性能有积极作用
n32 n64出现的原因是有个蛋疼的人觉得大多数应用程序在多两个寄存器传参的时候性能会好一些，所以，叫new abi，后来有人发现32位的new abi在code size和性能方面比64&& 位new abi好，当然，这只是无心之失罢了。&& 说不好性能上谁好谁差，毕竟现实世界的程序不是benchmark，随便造点儿看上去很美的数据就发看上去很牛逼的paper了。&&&& 2，内存大小（架构寻址空间）
64程序使用的内存又比32位大，对性能有副作用。
当然要找 32 位比 64 位跑得快的也很容易，找用内存多的就行了 && 3，数据宽度
要找一个 64 位跑得比 32 位快的程序还是很容易的.. 大量 64 位整数运算，或者大量浮点运算，然后内存又用得不多的程序，快百分之几十也正常得很.. && 4，指令密度（代码尺寸，指针长度）
做 x32 的动机不复杂啊，H.J. Lu 他们帮过一个 presentation（），无非就是说 x86-64 比 ia32 好太多了，可惜很多情况下指针没必要是 64 位，所以他们想把 x86-64 和 ia32 的优点给集合在一起&&
按维基百科的说法，这种 ABI 在 2003 年 AMD64 刚发布的时候就有人提过了，后来 Knuth 老爷子又在 2008 年呼吁了一下&&
benchmark 结果在 x32 的主页上就有： &&
比 x86-64 快的那部分基本上就可以认为是指针大小的改变带来的，比 32 位快的那部分基本上就可以认为是寄存器带来的（增多、变长、传参、RIP-relative addressing）&& （当然 x32 网站上的 benchmark 也不是很客观，选择性地取了对 x32 最有利的数据）&& 假定两个系统都是4G，我的方法是比较指令密度（平均每条执行的代码长度下包含的有效操作数），相同的workload指令密度越大越好。
补充一句：经过ms-rom的那些指令除外，他们不应该算是一条指令。
如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&& 很明显能得到更多L1-I命中或者减少指令运行时间。&& 在x32之前intel compiler就有个选项叫-auto_ilp32。HJ会不清楚这东西的用途？会拍脑袋说我们做个x32？更早的64位unix系统基本都支持lp64和ilp32两种data mode，会没有人对比过这两种模式的优缺点？&& 如edx, rdx真实包含的内容为0x,两条指令自然等价，此时32位指令下指令密度更大，且会产生指令缓存更好的结果，若比较的数据是64位，32位指令需要比较两次当然64位指令密度大。&&&&&& 5，iCache大小
icache miss最大的问题是不但自身阻碍流水线向前，由于instruction miss导致取数据&& 时候产生气泡，这样无法利用cache,memory的throughput latency,全部转换成access&&
latency.因此必须及时修正。&& 如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&& 很明显能得到更多L1-I命中或者减少指令运行时间。&& 至于i-cache的问题，不同的workload有不同的反应，但是总体来说减少其Miss是对的。
指令cache对性能影响？&& 由于前端是in order所以一旦产生缺失，严重阻碍后面的代码，导致的latency大于dcache。&& X32的性能提升也可以说由于其对应的32位指令的指令密度大于64位系统，&& 但是他们的性能提升却是来自于d-cache（429-mcf）。&& 如果是手工写的代码我们甚至引入了8位指令。&& cavium 的core 内icache 已经达到 78KB, intel 虽然是32KB但是他有core内L2，&& 多核系统大量测试中icache miss 表现的非常严重。
对于networking应用，为了保证延迟小，对于不同的packet类型要能第一时间在l1 i$命中 handler&& 而且一般是control plane&& 这种处理器的dataplane是hardware engine做的，而且即使对于control plane的packet, 对d-cache也有优化，类似于io-coherency logic可以做到让packet header在l1 d-cache中，payload在L2这样，反而对d-cache要求并不是那么高。&& OLTP, 当然还有我们的应用程序，都表现出对icache的问题。&& 至于你提到无法线性扩展，我们的结论是其制约于：应用程序&&& cache cohrenece & wire latency &总线带宽&内部互联架构 & 透明于OS的线程调度如 fine grain /coarse grain/smt & die size & 制程工艺，反倒与dcache关系很小。&& x32的上面由于其指令密度大于完全的64位指令，比如movq edx, (%eax), movq rdx, (%rax) 明显前者指令密度更大，虽然icache此时不是瓶颈，指令密度大间接给dcache带来了好处。注：x32 这个结论是文章上说的，但是我到是感到由于L2&L3是unified cache,dcache使用变小 icache一定也会变好，难道性能的提升真的完全来自于dcache ???&&&&&& movl %edx, (%eax)&& movq %rdx,(%rax)&&&& 这两个一样吧，前面的要 67 前缀，后面的要 48 前缀&&&& gcc -mx32 现在就大量生成 (%eax) 这样的寻址，即使能够推断出 %rax 的高 32 位是全 0。你们有空贡献点代码吧，这种情况下生成 (%rax) 就好了..&&&& x32 下面 (%esp) 基本可以无条件替换成 (%rsp)，gcc 现在也没做&&&& Cavium Octeon在使用中的确碰到i$ miss带来的性能损失，而d$反而没有那么严重的问题。&& d$即使有问题，也相对容易分析问题原因，并且解决，而i$则难的多。&&&& 我们的elf大概50M左右，根据profiling可以很明确的得出性能下降是i$造成的，但是一直没法解决这个问题。&&
后来根据这篇老论文[1]做了一些工作，i$ miss降低到了可接受范围，packet rate也上升到了可接受范围。&& 但这不是一个持久的解决方案，因为代码一直在增加，业务完全不相关部分的代码增加和修改都会导致关键路径上的i$增加（或者减少，基本靠蒙），而我们没法每次代码修改都做一次profiling-修改directed call graph，所以这个方案暂时搁置了。&&
不知道 @MaLing 有啥妙计可以共享？&&&& [1]: && 是否可以考虑把不同的handler bind到不同的core上？&& 已经是这么做的了。当然粒度还比较粗，应该可以再做细一些。但是细也有个极限，总共就那么多core。&& 话说回来，似乎除此之外没有其它办法解决i$ miss了。&& Pentium 4的trace cache这种机制没准能好一些，类似于存储程序的热路径，而不是简单的从地址去match&&&& 硬件能这么做，软件就没辙了&&&& 不过我倒是有个想法，不是那篇论文里说的那样把热路径上的routine给layout在一起，而是把热路径上的routine给layout在不同的cache line或者set里。而可以这么做的假设是，对于指定的一款processor，可以明确的知道virtual address到cache line的对应。&&&& 比如routineA和routineB是热路径上的两个routine，那么我们就得让routineA和routineB的set index不同或者tag不同。如果这款processor的virtual address里有几个低位bits是对应set index，那么就得让linker在layout的时候关照这两个routine。当然一般来说linker不知道运行时的virtual address，但可以以.text的起始位置为原点，算两个routine的相对地址，因为要比较的一般来说是低位，所以相对地址就够了。&&&& 当然，这得把逻辑写到linker里（或者是plugin），而且还是得以runtime profiling的结果来做参照。具体操作起来还是很麻烦。&&&&&& 6，数据cache大小
x32相对于x64的性能提升是来自于Icache还是dcache？&& dcache, 指针长度变少使用cache存储较少。&& 至少对speccpu rate来说，仍然是d$的因素导致无法线性扩展。&& 从编译器的角度看，d$导致的性能问题仍然是主流问题 && 7，综合
他们就是从代码密度去说的，同一个应用程序在64位和32位就是谁的代码密度大，谁的I-cache的miss率低，所以性能更好。前提是同一个程序比较的是I-CAHCE，D-CACHE的效率是相当的。&&&&&&&&当然从general的角度来说，CPU性能的瓶颈在D-CACHE的命中率上不高，而在I-cache上其实已经很高了，所以认为D-CACHE是性能的瓶颈。&&&&&&&& 感谢下列id在此问题讨论上作出的杰出贡献
@gdss @houge @vonNeumann @Aquamarine @MaLing @pxa255 @rockyzhang @philbloo @mcx && -- && ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
娶柠檬妻发信人: mcx (娶柠檬妻), 信区: CSArch
标&&题: Re: 64位系统是否比32位系统计算速度快
发信站: 水木社区 (Mon Aug 31 08:40:54 2015), 站内 && 感谢友版版主辛勤的整理工作。已推荐上首页。
【 在 tianbing1212 (tianbing) 的大作中提到: 】
: 标&&题: 64位系统是否比32位系统计算速度快
: 发信站: 水木社区 (Sun Aug 30 15:23:11 2015), 站内
: （应@mcx之约，对本贴爬楼，整理如下）
: 【问题的提出】
: 同一个程序，分别在64位系统和32位系统下编译运行，64位系统是否一定比32位系统要快？如果是，原理是什么？&&
: 假定CPU是一个型号，内存均为4G，都是linux系统。
: 【考虑的因素】
: “64位”系统的不同含义对性能产生了不同的影响
: 1，寄存器数量
: 有的体系结构，比如x86,64位比32位多几个寄存器，对性能有积极作用
: n32 n64出现的原因是有个蛋疼的人觉得大多数应用程序在多两个寄存器传参的时候性能会好一些，所以，叫new abi，后来有人发现32位的new abi在code size和性能方面比64&&
: 位new abi好，当然，这只是无心之失罢了。&&
: 说不好性能上谁好谁差，毕竟现实世界的程序不是benchmark，随便造点儿看上去很美的数据就发看上去很牛逼的paper了。&&
: 2，内存大小（架构寻址空间）
: 64程序使用的内存又比32位大，对性能有副作用。
: 当然要找 32 位比 64 位跑得快的也很容易，找用内存多的就行了
: 3，数据宽度
: 要找一个 64 位跑得比 32 位快的程序还是很容易的.. 大量 64 位整数运算，或者大量浮点运算，然后内存又用得不多的程序，快百分之几十也正常得很..
: 4，指令密度（代码尺寸，指针长度）
: 做 x32 的动机不复杂啊，H.J. Lu 他们帮过一个 presentation（），无非就是说 x86-64 比 ia32 好太多了，可惜很多情况下指针没必要是 64 位，所以他们想把 x86-64 和 ia32 的优点给集合在一起&&
: 按维基百科的说法，这种 ABI 在 2003 年 AMD64 刚发布的时候就有人提过了，后来 Knuth 老爷子又在 2008 年呼吁了一下&&
: benchmark 结果在 x32 的主页上就有： &&
: 比 x86-64 快的那部分基本上就可以认为是指针大小的改变带来的，比 32 位快的那部分基本上就可以认为是寄存器带来的（增多、变长、传参、RIP-relative addressing）&&
: （当然 x32 网站上的 benchmark 也不是很客观，选择性地取了对 x32 最有利的数据）&&
: 假定两个系统都是4G，我的方法是比较指令密度（平均每条执行的代码长度下包含的有效操作数），相同的workload指令密度越大越好。
: 补充一句：经过ms-rom的那些指令除外，他们不应该算是一条指令。
: 如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&&
: 很明显能得到更多L1-I命中或者减少指令运行时间。&&
: 在x32之前intel compiler就有个选项叫-auto_ilp32。HJ会不清楚这东西的用途？会拍脑袋说我们做个x32？更早的64位unix系统基本都支持lp64和ilp32两种data mode，会没有人对比过这两种模式的优缺点？&&
: 如edx, rdx真实包含的内容为0x,两条指令自然等价，此时32位指令下指令密度更大，且会产生指令缓存更好的结果，若比较的数据是64位，32位指令需要比较两次当然64位指令密度大。&&&&
: 5，iCache大小
: icache miss最大的问题是不但自身阻碍流水线向前，由于instruction miss导致取数据&&
: 时候产生气泡，这样无法利用cache,memory的throughput latency,全部转换成access&&
: latency.因此必须及时修正。&&
: 如果 cmp $256, %edx, /cmp $256, %rdx,我当然选择32位系统而不是64位,因为同样的有效操作数，一条指令下前者更省空间。但如果比较一个64位的数，我当然选择64位.&&
: 很明显能得到更多L1-I命中或者减少指令运行时间。&&
: 至于i-cache的问题，不同的workload有不同的反应，但是总体来说减少其Miss是对的。
: 指令cache对性能影响？&&
: 由于前端是in order所以一旦产生缺失，严重阻碍后面的代码，导致的latency大于dcache。&&
: X32的性能提升也可以说由于其对应的32位指令的指令密度大于64位系统，&&
: 但是他们的性能提升却是来自于d-cache（429-mcf）。&&
: 如果是手工写的代码我们甚至引入了8位指令。&&
: cavium 的core 内icache 已经达到 78KB, intel 虽然是32KB但是他有core内L2，&&
: 多核系统大量测试中icache miss 表现的非常严重。
: 对于networking应用，为了保证延迟小，对于不同的packet类型要能第一时间在l1 i$命中 handler&&
: 而且一般是control plane&&
: 这种处理器的dataplane是hardware engine做的，而且即使对于control plane的packet, 对d-cache也有优化，类似于io-coherency logic可以做到让packet header在l1 d-cache中，payload在L2这样，反而对d-cache要求并不是那么高。&&
: OLTP, 当然还有我们的应用程序，都表现出对icache的问题。&&
: 至于你提到无法线性扩展，我们的结论是其制约于：应用程序&&& cache cohrenece & wire latency &总线带宽&内部互联架构 & 透明于OS的线程调度如 fine grain /coarse grain/smt & die size & 制程工艺，反倒与dcache关系很小。&&
: x32的上面由于其指令密度大于完全的64位指令，比如movq edx, (%eax), movq rdx, (%rax) 明显前者指令密度更大，虽然icache此时不是瓶颈，指令密度大间接给dcache带来了好处。注：x32 这个结论是文章上说的，但是我到是感到由于L2&L3是unified cache,dcache使用变小 icache一定也会变好，难道性能的提升真的完全来自于dcache ???&&&&
: movl %edx, (%eax)&& movq %rdx,(%rax)&&&&
: 这两个一样吧，前面的要 67 前缀，后面的要 48 前缀&&&&
: gcc -mx32 现在就大量生成 (%eax) 这样的寻址，即使能够推断出 %rax 的高 32 位是全 0。你们有空贡献点代码吧，这种情况下生成 (%rax) 就好了..&&&&
: x32 下面 (%esp) 基本可以无条件替换成 (%rsp)，gcc 现在也没做&&
: Cavium Octeon在使用中的确碰到i$ miss带来的性能损失，而d$反而没有那么严重的问题。&&
: d$即使有问题，也相对容易分析问题原因，并且解决，而i$则难的多。&&&&
: 我们的elf大概50M左右，根据profiling可以很明确的得出性能下降是i$造成的，但是一直没法解决这个问题。&&
: 后来根据这篇老论文[1]做了一些工作，i$ miss降低到了可接受范围，packet rate也上升到了可接受范围。&&
: 但这不是一个持久的解决方案，因为代码一直在增加，业务完全不相关部分的代码增加和修改都会导致关键路径上的i$增加（或者减少，基本靠蒙），而我们没法每次代码修改都做一次profiling-修改directed call graph，所以这个方案暂时搁置了。&&
: 不知道 @MaLing 有啥妙计可以共享？&&&&
: 是否可以考虑把不同的handler bind到不同的core上？&&
: 已经是这么做的了。当然粒度还比较粗，应该可以再做细一些。但是细也有个极限，总共就那么多core。&&
: 话说回来，似乎除此之外没有其它办法解决i$ miss了。&&
: Pentium 4的trace cache这种机制没准能好一些，类似于存储程序的热路径，而不是简单的从地址去match&&
: 硬件能这么做，软件就没辙了&&&&
: 不过我倒是有个想法，不是那篇论文里说的那样把热路径上的routine给layout在一起，而是把热路径上的routine给layout在不同的cache line或者set里。而可以这么做的假设是，对于指定的一款processor，可以明确的知道virtual address到cache line的对应。&&&&
: 比如routineA和routineB是热路径上的两个routine，那么我们就得让routineA和routineB的set index不同或者tag不同。如果这款processor的virtual address里有几个低位bits是对应set index，那么就得让linker在layout的时候关照这两个routine。当然一般来说linker不知道运行时的virtual address，但可以以.text的起始位置为原点，算两个routine的相对地址，因为要比较的一般来说是低位，所以相对地址就够了。&&&&
: 当然，这得把逻辑写到linker里（或者是plugin），而且还是得以runtime profiling的结果来做参照。具体操作起来还是很麻烦。&&
: 6，数据cache大小
: x32相对于x64的性能提升是来自于Icache还是dcache？&&
: dcache, 指针长度变少使用cache存储较少。&&
: 至少对speccpu rate来说，仍然是d$的因素导致无法线性扩展。&&
: 从编译器的角度看，d$导致的性能问题仍然是主流问题
: 他们就是从代码密度去说的，同一个应用程序在64位和32位就是谁的代码密度大，谁的I-cache的miss率低，所以性能更好。前提是同一个程序比较的是I-CAHCE，D-CACHE的效率是相当的。&&
:&&&&&&当然从general的角度来说，CPU性能的瓶颈在D-CACHE的命中率上不高，而在I-cache上其实已经很高了，所以认为D-CACHE是性能的瓶颈。&&
: 感谢下列id在此问题讨论上作出的杰出贡献
: @gdss @houge @vonNeumann @Aquamarine @MaLing @pxa255 @rockyzhang @philbloo @mcx
: ※ 来源:·水木社区 ·[FROM: 211.100.31.*]
一袭尘，多少红颜春风的笑。
一片月，万千征人如霜的情。
一汪水，些许女子幽幽的怨。
一爿屋，那个人儿眷眷的心。 &&&& ※ 来源:·水木社区 newsmth.net·[FROM: 210.76.108.*]
吟游诗人发信人: BattleMech (吟游诗人), 信区: CSArch
标&&题: Re: [求助]求专业解答：64位系统是否比32位系统计算速度快
发信站: 水木社区 (Mon Aug 31 13:07:07 2015), 站内 && 32位架构内存就4G, 不够用啊。
-- && ※ 来源:·水木社区 ·[FROM: 182.48.110.*]
文章数:70&分页: