POPPUR爱换

 找回密码
 注册

QQ登录

只需一步,快速开始

手机号码,快捷登录

搜索
查看: 2694|回复: 13
打印 上一主题 下一主题

求比较两个处理器的性能 架构牛人进!!!

[复制链接]
跳转到指定楼层
1#
发表于 2011-7-5 13:06 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 kakaku.bj.cn 于 2011-7-5 13:41 编辑

Xeon 5550  (2.67) vs Xeon 5640  (2.27)
遇到了怪问题

求问单线程程序跑在双路系统上从另一路的内存里调用数据会不会造成延迟?
具体描述在4,5楼
natsumi 该用户已被删除
2#
发表于 2011-7-5 13:10 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

3332243 该用户已被删除
3#
发表于 2011-7-5 13:15 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

4#
 楼主| 发表于 2011-7-5 13:28 | 只看该作者
3332243 发表于 2011-7-5 13:15
L5640吧,6C12T
Xeon 5550    4C8T

再看了一下确实是L5640,先不提核心数量,某程序是单线程的
现在的问题是,用同一个程序跑,X5550只需要0.2秒,而L5640需要0.3秒
之前我以为是x5640,L3比X5550高,所以单线程性能会更接近,所以结果无法接受
现在看到是L5640,单个核心的L3并不比X5550多,所以他们的性能差距可能会更接近频率差距
不过2.67/2.27也只有不到18%的频率差,为什么运算能力会相差那么多
回复 支持 反对

使用道具 举报

5#
 楼主| 发表于 2011-7-5 13:36 | 只看该作者
kakaku.bj.cn 发表于 2011-7-5 13:28
再看了一下确实是L5640,先不提核心数量,某程序是单线程的
现在的问题是,用同一个程序跑,X5550只需要 ...

说明一点细节:这个程序是在内存中的数据库里遍历一遍取得符合条件的行。数据库完全在内存里所以不涉及io
另一个细节:L5640的机器拥有两个cpu,而X5550只有1个;另外数据库是均匀地放在两个cpu所属的两边的内存里的
而程序是单线程,现在的猜想就是:会不会是单线程程序从另一路bus的内存里调用数据造成延迟?
回复 支持 反对

使用道具 举报

6#
发表于 2011-7-5 13:46 | 只看该作者
回复 kakaku.bj.cn 的帖子

记得曾经在哪里看到过一个测试, nehalam remote ram (跨cpu的), 性能是不错的, 具体数值忘了, 但应该不会比双 operton差.
回复 支持 反对

使用道具 举报

7#
发表于 2011-7-5 14:06 | 只看该作者
kakaku.bj.cn 发表于 2011-7-5 13:36
说明一点细节:这个程序是在内存中的数据库里遍历一遍取得符合条件的行。数据库完全在内存里所以不涉及io ...

第一  我不知道为什么你DB会加载到两个控制器下的内存里的   难道是很大很大导致一边放不下?  那为啥在5550的机器上单路的内存就够用了呢?

第二  访问另外一颗CPU下的内存是通过QPI总线访问另一颗CPU然后通过那颗CPU再访问到内存的先不说延迟   就是QPI总线的带宽也比CPU直接到内存的带宽窄多了
回复 支持 反对

使用道具 举报

8#
 楼主| 发表于 2011-7-5 14:13 | 只看该作者
redseabay 发表于 2011-7-5 13:46
回复 kakaku.bj.cn 的帖子

记得曾经在哪里看到过一个测试, nehalam remote ram (跨cpu的), 性能是不错的,  ...

我感兴趣你的话题的,不过remote ram这个关键字貌似不对查不到
回复 支持 反对

使用道具 举报

3332243 该用户已被删除
9#
发表于 2011-7-5 14:16 | 只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
回复 支持 反对

使用道具 举报

10#
 楼主| 发表于 2011-7-5 14:17 | 只看该作者
太虚公 发表于 2011-7-5 14:06
第一  我不知道为什么你DB会加载到两个控制器下的内存里的   难道是很大很大导致一边放不下?  那为啥在5 ...

是的,一边48g,一共96g内存,数据库70g,均匀放在两边
那个X5550的是小型机,分到单cpu就不止70g
回复 支持 反对

使用道具 举报

11#
发表于 2011-7-5 14:28 | 只看该作者
kakaku.bj.cn 发表于 2011-7-5 14:17
是的,一边48g,一共96g内存,数据库70g,均匀放在两边
那个X5550的是小型机,分到单cpu就不止70g

这种单线程大内存需求唯一的办法是个单个CPU分配大内存别的没办法,QPI带宽和内存带宽就不是一个数量级的    延迟的相差也在一个数量级的差别
回复 支持 反对

使用道具 举报

12#
发表于 2011-7-7 07:07 | 只看该作者
kakaku.bj.cn 发表于 2011-7-5 14:13
我感兴趣你的话题的,不过remote ram这个关键字貌似不对查不到

我一时也找不到了, 这里有人做了一个测试, 一个应用访问本地内存和远端内存, 性能差异  22%, 嗯, 这算不大的了.

http://kevinclosson.wordpress.com/2009/08/14/intel-xeon-5500-nehalem-ep-numa-versus-interleaved-memory-aka-suma-there-is-no-difference-a-forced-confession/

回复 支持 反对

使用道具 举报

13#
发表于 2011-7-7 07:12 | 只看该作者
kakaku.bj.cn 发表于 2011-7-5 14:13
我感兴趣你的话题的,不过remote ram这个关键字貌似不对查不到

哦, 我搞错了, 不是remote ram, 是 remote memory, google   nahalem remote memory performane 可以找到一篇 pdf, 名字是  Memory Performance of Xeon 7500 (Nehalem-EX) based Systems,
里面说

Access to remote memory
Solely local memory was used in the previously described tests both with STREAM as well as with
SPECint_rate_base2006, i.e. every processor accesses DIMM modules of its own memory channels.
Modules of the other processors are not accessed or are hardly accessed via the QPI link. This situation is
representative, insofar as it also exists for the majority of memory accesses of real applications thanks to
NUMA support in the operating system and system software.
The following table shows the effect of the opposite case for both benchmarks. The exclusive use of remote
memory was enforced by measures such as explicit process binding. The table shows the deterioration in
the measurement result in per cent.

Benchmark
Effect of the exclusive use of remote  memory
STREAM                         -25%
SPECint_rate_base2006  -13%



不过这篇不是我以前看到的, 我以前看到的有代码的, 直接测内存, 不是用现成 benchmark 套件, 而且和其他 numa 系统比较, 结论说 nahalem 的 remote memory 比起常规 numa 系统的算好很多了.
回复 支持 反对

使用道具 举报

14#
 楼主| 发表于 2011-7-7 09:21 | 只看该作者
redseabay 发表于 2011-7-7 07:12
哦, 我搞错了, 不是remote ram, 是 remote memory, google   nahalem remote memory performane 可以找到 ...

好的 thanku
我去研究一下文档
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

广告投放或合作|网站地图|处罚通告|

GMT+8, 2025-8-29 22:12

Powered by Discuz! X3.4

© 2001-2017 POPPUR.

快速回复 返回顶部 返回列表