s**********e
发帖数: 153 | | f****g
发帖数: 23666 | 2 这是显然，必入了
不过就凭sb这个sb，这是做梦
【在 s**********e 的大作中提到】
: RT
| s********3
发帖数: 3476 | | S****s
发帖数: 11288 | | z**r
发帖数: 17771 | 5 想啥呢？人心不足蛇吞象啊，还是给这个产业一个比较合理的价格比较好
【在 s**********e 的大作中提到】
: RT
| a********m
发帖数: 15480 | 6 499是有点低。不过多于６００俺肯定是不觉得合适了。
【在 z**r 的大作中提到】
: 想啥呢？人心不足蛇吞象啊，还是给这个产业一个比较合理的价格比较好
| a******1
发帖数: 2340 | 7 现在就算不要touch screen NFC，找一个ultrabook， 1080P分辨率，i5/i7配置的怎么
说也要700+ | s*****o
发帖数: 1565 | 8 atom的pro现在有600的，说不定等thinkgiving给个discount就499了 | a********m
发帖数: 15480 | 9 atom还是算了。
【在 s*****o 的大作中提到】
: atom的pro现在有600的，说不定等thinkgiving给个discount就499了
| d**********I
发帖数: 2057 | 10 11"的macbook air没有touch,能做的没有pro多,都卖1000.800会是不错的deal.
【在 s**********e 的大作中提到】
: RT
| | | s*****o
发帖数: 1565 | 11 最近开始感觉不能触屏的笔记本马上就是上个时代的东西了...
【在 d**********I 的大作中提到】
: 11"的macbook air没有touch,能做的没有pro多,都卖1000.800会是不错的deal.
| G*****h
发帖数: 33134 | 12 显然的
没得摸都不好意思拿出来用
【在 s*****o 的大作中提到】
: 最近开始感觉不能触屏的笔记本马上就是上个时代的东西了...
| c*******r
发帖数: 603 | 13 我觉得干活用的笔记本，没太大必要摸。
而且对于干活用的、不是镜面屏的笔记本，摸了后屏幕全是指纹，也不太好吧
【在 s*****o 的大作中提到】
: 最近开始感觉不能触屏的笔记本马上就是上个时代的东西了...
| G*****h
发帖数: 33134 | 14 出门一般用不着干太多活
板子带着轻松多了
【在 c*******r 的大作中提到】
: 我觉得干活用的笔记本，没太大必要摸。
: 而且对于干活用的、不是镜面屏的笔记本，摸了后屏幕全是指纹，也不太好吧
| l******n
发帖数: 1683 | 15 会轻松太多么? surface pro本身重量已经2磅了, ultrabook的话也就3磅. 而且相对应
的, pro还得再加上键盘的重量.
【在 G*****h 的大作中提到】
: 出门一般用不着干太多活
: 板子带着轻松多了
| a********m
发帖数: 15480 | 16 mba 11寸2.34磅。差不多重量。
【在 l******n 的大作中提到】
: 会轻松太多么? surface pro本身重量已经2磅了, ultrabook的话也就3磅. 而且相对应
: 的, pro还得再加上键盘的重量.
| G*****h
发帖数: 33134 | 17 别家的可以做得更轻啊
原则上应该可以跟安板差不多
再加个薄膜键盘的分量
【在 l******n 的大作中提到】
: 会轻松太多么? surface pro本身重量已经2磅了, ultrabook的话也就3磅. 而且相对应
: 的, pro还得再加上键盘的重量.
| l******n
发帖数: 1683 | 18 i5的板子恐怕够呛吧
【在 G*****h 的大作中提到】
: 别家的可以做得更轻啊
: 原则上应该可以跟安板差不多
: 再加个薄膜键盘的分量
| G*****h
发帖数: 33134 | 19 又不是每个人都需要 i5
【在 l******n 的大作中提到】
: i5的板子恐怕够呛吧
| l******n
发帖数: 1683 | 20 atom本的话, 你先回答我一个问题, 为啥之前netbook的市场一下就崩掉了.
【在 G*****h 的大作中提到】
: 又不是每个人都需要 i5
| | | G*****h
发帖数: 33134 | 21 性能差太多了
其实偶最常用的还是个netbook
【在 l******n 的大作中提到】
: atom本的话, 你先回答我一个问题, 为啥之前netbook的市场一下就崩掉了.
| a********m
发帖数: 15480 | 22 现在性能不还是差太多。。。。
【在 G*****h 的大作中提到】
: 性能差太多了
: 其实偶最常用的还是个netbook
| G*****h
发帖数: 33134 | 23 现在提高了一些吧
虽然intel很不情愿
奈何arm压力太大
【在 a********m 的大作中提到】
: 现在性能不还是差太多。。。。
| a********m
发帖数: 15480 | 24 好像没啥大区别。
【在 G*****h 的大作中提到】
: 现在提高了一些吧
: 虽然intel很不情愿
: 奈何arm压力太大
| G*****h
发帖数: 33134 | 25 至少省电多了
巡航时间可以跟arm比比了
【在 a********m 的大作中提到】
: 好像没啥大区别。
| z*n
发帖数: 2893 | 26 因为tablet的form factor, 论CPU performance现在的4核A9还不如上一代的ATOM.
说了无数次了, 如果clover trail的性能还不够运行tablet, 那这一代的winrt/A/G板
子都不用看了, 里面的CPU只能更慢.
【在 l******n 的大作中提到】
: atom本的话, 你先回答我一个问题, 为啥之前netbook的市场一下就崩掉了.
| l******n
发帖数: 1683 | 27 cpu性能的话, 看这个测试, arm明显要强于上一代的atom.
http://www.phoronix.com/scan.php?page=article&item=gentoo_arm_x
而且说cpu本身性能没啥意义, 俺的老掉牙的optimus s手机, 600M的上一代armv6指令
集的cpu, 256M内存, 跑android还是能跑的, 但是要是上个ubuntu, 跑个xwindows, 我
看是够呛. atom win8板既然你们号称的卖点是兼容以往的x86应用, 那么对cpu性能的
要求就不仅仅是持平或者beat现在的arm.
【在 z*n 的大作中提到】
: 因为tablet的form factor, 论CPU performance现在的4核A9还不如上一代的ATOM.
: 说了无数次了, 如果clover trail的性能还不够运行tablet, 那这一代的winrt/A/G板
: 子都不用看了, 里面的CPU只能更慢.
| S*********a
发帖数: 1640 | 28 我用过Atom单核双核的Chrome Book，Youtube 720P的视频都卡得跟放PPT似的，用过的
ARM都比它强了。
【在 z*n 的大作中提到】
: 因为tablet的form factor, 论CPU performance现在的4核A9还不如上一代的ATOM.
: 说了无数次了, 如果clover trail的性能还不够运行tablet, 那这一代的winrt/A/G板
: 子都不用看了, 里面的CPU只能更慢.
| z*n
发帖数: 2893 | 29 N450那是上上代的ATOM了, 中间还有N2600/2800.
我记得我给你解释过这一代ARM的问题了. ARM的问题是访存代宽不够, 多核或者memory
intensive的测试不行. 比如nvidia的t3, 一旦屏幕刷新时GPU开始工作, CPU访存立刻
歇菜, 那时候四个核一起上还不如平时一个核快. 相比之下ATOM是更加balanced的系统.
跑win8/winrt, 信我一句, 我两种板子都摸过, ATOM的win8 tablet在性能上完胜t3的
winrt, 很明显能肉眼看出区别的那种.
从理论上讲, winRT/win32是native API在sandbox里运行, 会比javascript快, 是和
ndk一个量级的. 如果同样的计算, 在android上用javascript实现, 和用winrt/xaml的
metro实现比, 理论上讲类似native code的metro app应当快不少.
如果拿atom和i3/i5比那确实是蜗牛, 没有办法干真正的编译/视频转换之类的重活, 但
这就是个十寸的板子... 读书看片, 视频会议, 敲个文档,做个笔记什么的是绰绰有余
的.
win8 tablet/hybrid最大的优势是用户有选择只买一个设备, 而不是被迫用notebook +
tablet, 后者在win8之前几乎就是双倍的体积和费用.
【在 l******n 的大作中提到】
: cpu性能的话, 看这个测试, arm明显要强于上一代的atom.
: http://www.phoronix.com/scan.php?page=article&item=gentoo_arm_x
: 而且说cpu本身性能没啥意义, 俺的老掉牙的optimus s手机, 600M的上一代armv6指令
: 集的cpu, 256M内存, 跑android还是能跑的, 但是要是上个ubuntu, 跑个xwindows, 我
: 看是够呛. atom win8板既然你们号称的卖点是兼容以往的x86应用, 那么对cpu性能的
: 要求就不仅仅是持平或者beat现在的arm.
| z*n
发帖数: 2893 | 30 ...你估计要去找chromebook, 明显ATOM没开硬件加速. 不开硬件加速, ARM 720P也跑
不起来, 开了这两个就是比GPU, 720P应当就是小菜.
clover trail上面在IE里放Youtube是用hardware decoder的, 没啥好担心的, 其他
browser支持不支持不知道.
【在 S*********a 的大作中提到】
: 我用过Atom单核双核的Chrome Book，Youtube 720P的视频都卡得跟放PPT似的，用过的
: ARM都比它强了。
| | | l******n
发帖数: 1683 | 31 问题在于N450到N2600/2800单核性能长进其实不大, 主要差别只是从单核双线程到了双
核四线程, 同时提升了制造工艺. 而从上面的测试来看, 同频的 N450的单核性能在大多
数测试里面跟A9相比还有相当的差距.
ARM的带宽问题我在版面上看见有人说intel的人说有问题, 但是问题是从实际的内存带
宽测试结果来看, atom平台并不占优, 所以我对这个说法表示怀疑. 另外对于cpu的性能
, 我相信这个说法: 单核性能的提升总是有必要和有意义的, 至于堆多核的话, 对于普
通人来说, 4核及以上基本就是噱头了.
memory
统.
【在 z*n 的大作中提到】
: N450那是上上代的ATOM了, 中间还有N2600/2800.
: 我记得我给你解释过这一代ARM的问题了. ARM的问题是访存代宽不够, 多核或者memory
: intensive的测试不行. 比如nvidia的t3, 一旦屏幕刷新时GPU开始工作, CPU访存立刻
: 歇菜, 那时候四个核一起上还不如平时一个核快. 相比之下ATOM是更加balanced的系统.
: 跑win8/winrt, 信我一句, 我两种板子都摸过, ATOM的win8 tablet在性能上完胜t3的
: winrt, 很明显能肉眼看出区别的那种.
: 从理论上讲, winRT/win32是native API在sandbox里运行, 会比javascript快, 是和
: ndk一个量级的. 如果同样的计算, 在android上用javascript实现, 和用winrt/xaml的
: metro实现比, 理论上讲类似native code的metro app应当快不少.
: 如果拿atom和i3/i5比那确实是蜗牛, 没有办法干真正的编译/视频转换之类的重活, 但
| S*********a
发帖数: 1640 | 32 你Intel托吧，哈哈
Chrome浏览器里2D相关的Rendering的加速都是默认加开的，我刚还打开确认了一下。
即便怪到GPU头上，也说明是Atom带的Intel自家GPU不行啊。
清晰点的视频都看不舒服，上网本或是平板用途就废了一半了。
【在 z*n 的大作中提到】
: ...你估计要去找chromebook, 明显ATOM没开硬件加速. 不开硬件加速, ARM 720P也跑
: 不起来, 开了这两个就是比GPU, 720P应当就是小菜.
: clover trail上面在IE里放Youtube是用hardware decoder的, 没啥好担心的, 其他
: browser支持不支持不知道.
| n**s
发帖数: 2230 | 33 64GB开始，价格至少和64g牛排持平。电池续航时间现在都不敢公布。据用过样机的人
说过，就4个小时撑破了。 | z*n
发帖数: 2893 | 34 几个贴我一起回了. N450单核1.66GHz, CloverTrail 双核1.8G Hz... 内核差两代.
clover trail的spec int numbers:
http://www.anandtech.com/show/6340/intel-details-atom-z2760-clo
和同频(1.8G)A9比是1.20vs.1.14, 和4核的T3比throughput是1.54vs.1.25. 真正有差
距的是这一代的A9.
ARM/ATOM单核性能太差, 测试结果是大约1/2 Pentium M的水平, 对Android乱七八糟的
后台程序多核会有巨大帮助.
那位Youtube 720P的老弟, 我和你说了720P解压比的是GPU, 你需要找到为什么那
chromebook在atom平台上没有用硬解, 如果你已经打开了硬件加速那就是chromebook硬
件或者软件的问题. 我和你说了clover trail的板子用IE10看Youtube是硬解的, 流畅
度没问题.
大多
性能
【在 l******n 的大作中提到】
: 问题在于N450到N2600/2800单核性能长进其实不大, 主要差别只是从单核双线程到了双
: 核四线程, 同时提升了制造工艺. 而从上面的测试来看, 同频的 N450的单核性能在大多
: 数测试里面跟A9相比还有相当的差距.
: ARM的带宽问题我在版面上看见有人说intel的人说有问题, 但是问题是从实际的内存带
: 宽测试结果来看, atom平台并不占优, 所以我对这个说法表示怀疑. 另外对于cpu的性能
: , 我相信这个说法: 单核性能的提升总是有必要和有意义的, 至于堆多核的话, 对于普
: 通人来说, 4核及以上基本就是噱头了.
:
: memory
: 统.
| l******n
发帖数: 1683 | 35 差几代不是问题，关键是每一代都改近了啥。从n450到n2800的改进主要是工艺提升，
能耗下降，gpu性能提升和多堆了一个核心，单核性能上基本没有任何改进。
而最新一代的z2760,现在则只有intel自己公布的spec int和int_rate的成绩。单核成
绩的话，clover trail算是追上了同频的a9. rate的话,考虑到超线程的贡献，也算正
常。而且tegra 3只不过是最早的arm4核，就跟当初tegra2一样，抢第一的成分不少。
最后，spec的测试结果跟编译器的优化有很大关系，而编译方面正好是intel的强项，
所以这个结果估计对比实际使用是要打折扣的
【在 z*n 的大作中提到】
: 几个贴我一起回了. N450单核1.66GHz, CloverTrail 双核1.8G Hz... 内核差两代.
: clover trail的spec int numbers:
: http://www.anandtech.com/show/6340/intel-details-atom-z2760-clo
: 和同频(1.8G)A9比是1.20vs.1.14, 和4核的T3比throughput是1.54vs.1.25. 真正有差
: 距的是这一代的A9.
: ARM/ATOM单核性能太差, 测试结果是大约1/2 Pentium M的水平, 对Android乱七八糟的
: 后台程序多核会有巨大帮助.
: 那位Youtube 720P的老弟, 我和你说了720P解压比的是GPU, 你需要找到为什么那
: chromebook在atom平台上没有用硬解, 如果你已经打开了硬件加速那就是chromebook硬
: 件或者软件的问题. 我和你说了clover trail的板子用IE10看Youtube是硬解的, 流畅
| z*n
发帖数: 2893 | 36 我不知道你这些speculation的事实根据是什么,
我已经给了你spec_int的数据, 我也告诉你我实际摸过t3和clover trail的winrt/win8
板子,
atom的板子有眼睛和耳朵能看/听出来的性能优势.
我也和你解释过了从技术上讲为什么ARM实际使用的时候会感觉慢.
我觉得如果没有实际数据,没有实际使用过atom-based的板子的情况下不应当只凭猜测
认为一个东西会如何如何. 你如果没有数据应当打住了.
【在 l******n 的大作中提到】
: 差几代不是问题，关键是每一代都改近了啥。从n450到n2800的改进主要是工艺提升，
: 能耗下降，gpu性能提升和多堆了一个核心，单核性能上基本没有任何改进。
: 而最新一代的z2760,现在则只有intel自己公布的spec int和int_rate的成绩。单核成
: 绩的话，clover trail算是追上了同频的a9. rate的话,考虑到超线程的贡献，也算正
: 常。而且tegra 3只不过是最早的arm4核，就跟当初tegra2一样，抢第一的成分不少。
: 最后，spec的测试结果跟编译器的优化有很大关系，而编译方面正好是intel的强项，
: 所以这个结果估计对比实际使用是要打折扣的
| l******n
发帖数: 1683 | 37 spec_int的数据还是我给你的吧, 上面很清楚呀, 单核性能, 1.5G S4是1的话, 1.8G的
没有detailed信息的A9是1.14, 1.3G的Tegra3是0.86, 1.8G的z2760是1.2, 你自己算算
吧, 同频的A9跟z2760. 而且这个测试是intel自己的人做的, spec的测试结果是相当依
赖与编译优化的, 而且编译正是intel的长项.
z2760没有发布, 自然也就只有那么一个数据. 而D450 vs N2800, 随便看个数据吧:
http://www.51nb.com/?action-viewnews-itemid-67564.
单核性能显然没有长进. 而我之前给过你D450 vs A9的测试, D450显然是大幅落后.
另外, 随着google新chromebook发布, 新的基于A15的arm都已经出来了...
win8
数据? ARM带宽导致性能有问题老实说我只在版上看见之前有果轮在谈论A5的时候提到
过, 而且依据只有两个: 1. 据intel某某人说; 2. geekbench的测试. 可是这两者,
2是完全不靠谱的, 1的话, hoho.
【在 z*n 的大作中提到】
: 我不知道你这些speculation的事实根据是什么,
: 我已经给了你spec_int的数据, 我也告诉你我实际摸过t3和clover trail的winrt/win8
: 板子,
: atom的板子有眼睛和耳朵能看/听出来的性能优势.
: 我也和你解释过了从技术上讲为什么ARM实际使用的时候会感觉慢.
: 我觉得如果没有实际数据,没有实际使用过atom-based的板子的情况下不应当只凭猜测
: 认为一个东西会如何如何. 你如果没有数据应当打住了.
| z*n
发帖数: 2893 | 38 1.8G 同频 1.14 vs. 1.2, 而且这还是CPU intenstive的单核测试... throughput测试
ARM情况更差.
有访存瓶颈的情况没有可能有linear speedup, 我和你说过了实际测试的时候T3在GPU
全开时候主CPU四个还不如平时1个快, 而ATOM没有这问题.
你有没有真正用过clover trail的板子? 没用过别猜测了好不好?
,
【在 l******n 的大作中提到】
: spec_int的数据还是我给你的吧, 上面很清楚呀, 单核性能, 1.5G S4是1的话, 1.8G的
: 没有detailed信息的A9是1.14, 1.3G的Tegra3是0.86, 1.8G的z2760是1.2, 你自己算算
: 吧, 同频的A9跟z2760. 而且这个测试是intel自己的人做的, spec的测试结果是相当依
: 赖与编译优化的, 而且编译正是intel的长项.
: z2760没有发布, 自然也就只有那么一个数据. 而D450 vs N2800, 随便看个数据吧:
: http://www.51nb.com/?action-viewnews-itemid-67564.
: 单核性能显然没有长进. 而我之前给过你D450 vs A9的测试, D450显然是大幅落后.
: 另外, 随着google新chromebook发布, 新的基于A15的arm都已经出来了...
:
: win8
| l******n
发帖数: 1683 | 39 1.8G同频 1.14 vs 1.2. 但是问题是, 文章中没有这个1.8G A9的任何信息, 好歹总得说
说是那家的东西吧, 另外这个是intel自己家做的测试. 我前面说的很清楚, spec测试结
果跟编译优化有很大关系. intel跑这个测试的时候不可能不针对自己的atom进行充分优
化.
而throughout测试, 从2核到4核性能要double本来也不是那么容易的事情, 你去spec网站
查查intel自己的cpu的成绩, 单核vs双核vs4核, 4核基本也就是单核的3.3X, 双核4线程
能到单核的2.2X. 而且作为ref的T3, 本来情况就跟T2一样, 主要恐怕还是为了抢哪个第
一的名头, 性能上在现在的arm4核里面本来就是垫底的.
而且多核这个东西, 对于个人使用来说, 双核是有意义的, 但是4核及以上基本就是噱
头.
对整机性能没啥帮助.
GPU
clover trail的板子市面上都没有, 上哪用去. 但是intel自己的官方测试成绩在哪放
着.
难道你要向果轮看齐么, 不看测试看体验.
【在 z*n 的大作中提到】
: 1.8G 同频 1.14 vs. 1.2, 而且这还是CPU intenstive的单核测试... throughput测试
: ARM情况更差.
: 有访存瓶颈的情况没有可能有linear speedup, 我和你说过了实际测试的时候T3在GPU
: 全开时候主CPU四个还不如平时1个快, 而ATOM没有这问题.
: 你有没有真正用过clover trail的板子? 没用过别猜测了好不好?
:
: ,
| z*n
发帖数: 2893 | 40 作为一个技术人员应当实事求是，现在唯一的测试数据说明clover trail无论从单线程
指标和多线程throughput都优于ARM. 你怀疑的其他东西都没有任何证据支持，你总不
能靠主观怀疑来当论据。
况且你也没有真用过clover trail的板子。我和你说过了T3在GPU全开的时候访存有瓶
颈，主Cpu这时候连正常的时候的25%性能都没有，这也是我见到的测试数据支持的。
我再和你强调一次， clover trail的win8板子性能上完胜t3的板子，从公开的
benchmark, 到我自己的实际体验，到我见到的实验室测试数据都是支持这个结论的。
你如果没有同样的实际数据支持你的观点我建议你不要下atom不行的结论。
得说
试结
分优
网站
线程
个第
【在 l******n 的大作中提到】
: 1.8G同频 1.14 vs 1.2. 但是问题是, 文章中没有这个1.8G A9的任何信息, 好歹总得说
: 说是那家的东西吧, 另外这个是intel自己家做的测试. 我前面说的很清楚, spec测试结
: 果跟编译优化有很大关系. intel跑这个测试的时候不可能不针对自己的atom进行充分优
: 化.
: 而throughout测试, 从2核到4核性能要double本来也不是那么容易的事情, 你去spec网站
: 查查intel自己的cpu的成绩, 单核vs双核vs4核, 4核基本也就是单核的3.3X, 双核4线程
: 能到单核的2.2X. 而且作为ref的T3, 本来情况就跟T2一样, 主要恐怕还是为了抢哪个第
: 一的名头, 性能上在现在的arm4核里面本来就是垫底的.
: 而且多核这个东西, 对于个人使用来说, 双核是有意义的, 但是4核及以上基本就是噱
: 头.
| | | j*****y
发帖数: 2042 | 41 问题是卖499对整个industry没有任何好处，PC厂家快速死亡，微软因为找不到新biz
model，device又不赚钱，ads拼不过谷歌，也爽一把就死，然后IT码工们都要失业了……
【在 f****g 的大作中提到】
: 这是显然，必入了
: 不过就凭sb这个sb，这是做梦
| l******n
发帖数: 1683 | 42
我觉得你的逻辑很有问题, 现在唯一的intel自己的测试数据也没法说colover trail在单
核性能上能够beat A9. 最多不过是说colver trail终于追上了A9而已. 不过现在A15的产
品都已经出来了. 至于我怀疑的部分, spec测试结果严重依赖于编译优化这个事实,
intel编译方面很强也是事实, 联想一下当年intel vs amd, 结果估计多少有点猫腻.
而且现在spec官网仍然查不到这个结果.
你这说来说去都是空口说白话. 前面给过你数据, D450惨败给A9, 你要说D450是上上代的
东西, 那么就看上代吧, N2800vsD450的数据也给你了, 单核性能无长进. 然后你就又扯
即将上市的z2760, 使劲的强调他能完胜t3, 不过又不拿出数据来. 而且关键是, t3是啥
时候release的东西, 都差不多一年了, 而且大家都知道, nvidia出的无论是t2还是t3,
都是抢时间的东东, 说性能的话, t2在双核A9里面是垫底, t3在四核A9里面还是垫底.
你们整天跟个垫底的比来比去, 能不能稍微有点追求呀.
【在 z*n 的大作中提到】
: 作为一个技术人员应当实事求是，现在唯一的测试数据说明clover trail无论从单线程
: 指标和多线程throughput都优于ARM. 你怀疑的其他东西都没有任何证据支持，你总不
: 能靠主观怀疑来当论据。
: 况且你也没有真用过clover trail的板子。我和你说过了T3在GPU全开的时候访存有瓶
: 颈，主Cpu这时候连正常的时候的25%性能都没有，这也是我见到的测试数据支持的。
: 我再和你强调一次， clover trail的win8板子性能上完胜t3的板子，从公开的
: benchmark, 到我自己的实际体验，到我见到的实验室测试数据都是支持这个结论的。
: 你如果没有同样的实际数据支持你的观点我建议你不要下atom不行的结论。
:
: 得说
| z*n
发帖数: 2893 | 43 我已经给你无数次这个引用了.
http://www.anandtech.com/show/6340/intel-details-atom-z2760-clo
这是现在能找到的唯一z2760的测试数据,你有疑问需要证据，否则就和怀疑中国游泳
吃药一样，那才是空口说白话. 从那引用的数据,1.8G同频单线程,用两核的clover
trail和4核的t3比throughput都是clover trail完胜．你对于这数据还有什么不明白的
?
t3 1.3就是N7里面的CPU... 估计是用得最多的4核ARM之一，一大堆市面上的pad还是
dual core，那四核t3已经是比2核1.8G好不少了．如果你有数据,欢迎共享．如果没有
用过clover trail的板子, 又没有真实数据challenge上面的测试结果，你还是把自己
的怀疑留给自己，别象那个美国教练一样，用牵强的理由怀疑自己不想面对的事实.
从我实际摸t3和clover trail的win8板子的结果，atom完胜,没有任何疑问．同样的价
钱我是不会考虑t3的板子的. 你非要选明显spec结果不行,又有明显访存瓶颈的系统是
你自己的问题.
在单
的产
代的
又扯
是啥
t3,
【在 l******n 的大作中提到】
:
: 我觉得你的逻辑很有问题, 现在唯一的intel自己的测试数据也没法说colover trail在单
: 核性能上能够beat A9. 最多不过是说colver trail终于追上了A9而已. 不过现在A15的产
: 品都已经出来了. 至于我怀疑的部分, spec测试结果严重依赖于编译优化这个事实,
: intel编译方面很强也是事实, 联想一下当年intel vs amd, 结果估计多少有点猫腻.
: 而且现在spec官网仍然查不到这个结果.
: 你这说来说去都是空口说白话. 前面给过你数据, D450惨败给A9, 你要说D450是上上代的
: 东西, 那么就看上代吧, N2800vsD450的数据也给你了, 单核性能无长进. 然后你就又扯
: 即将上市的z2760, 使劲的强调他能完胜t3, 不过又不拿出数据来. 而且关键是, t3是啥
: 时候release的东西, 都差不多一年了, 而且大家都知道, nvidia出的无论是t2还是t3,
| x******a
发帖数: 6336 | 44 0.99更火
【在 s**********e 的大作中提到】
: RT
| l******n
发帖数: 1683 | 45 你还真搞笑. 这个引用我最先给你的. 而且数据显示得很清楚, 如果你看不懂我就再帮忙
一下. 单核部分:
S4(1.5G) 1.00 1.00
Dual-Core A9(1.8G) 1.14 1.14/(1.8/1.5)=0.95
T3(1.3G) 0.86 0.86/(1.3/1.5)=0.99
Z2760 1.20 1.20/(1.8/1.5)=1.00
这个你也好意思叫完胜么. 而且就算是你一直津津乐道的1.20vs1.14, 差别是多少, 5%.
你自己去看看spec官网的测试数据, 同样的cpu, 同样的硬件平台, report的测试结果
差个5%简直就是太正常的事情了. 要是用gcc编译的话, 比icc编译的结果差20-30%也不
稀奇, 这也就是我为啥一开始就说用新atom跑老x86应用的话, 表现要比这个结果打折扣
的原因.
至于多核, 大家其实都清楚, 双核有帮助, 四核目前就是专门用来跑分的. 对于用户来
说,
至关重要的还是单核性能.单核性能的话, 4核T3显然是不如1.8G的双核. 带宽方面T3也的
确是不够, 所以上个月amazon发布新的kindle的时候, 就敢声称用的双核OMAP4470要比
T3强.
而且就算如此, 回到上面你说的文章中的数据:
S4(1.5G) 1.00 1.00
Dual-Core A9(1.8G) 1.14 1.14/(1.8/1.5)=0.95
T3(1.3)G 1.25 1.25/(1.3/1.5)=1.44
Z2760 1.54 1.54/(1.8/1.5)=1.28
考虑到z2760是个2核4线程的cpu, 而intel一直声称超线程可以带来15-30%的性能提升.
这个
结果还是远远谈不上完胜.
【在 z*n 的大作中提到】
: 我已经给你无数次这个引用了.
: http://www.anandtech.com/show/6340/intel-details-atom-z2760-clo
: 这是现在能找到的唯一z2760的测试数据,你有疑问需要证据，否则就和怀疑中国游泳
: 吃药一样，那才是空口说白话. 从那引用的数据,1.8G同频单线程,用两核的clover
: trail和4核的t3比throughput都是clover trail完胜．你对于这数据还有什么不明白的
: ?
: t3 1.3就是N7里面的CPU... 估计是用得最多的4核ARM之一，一大堆市面上的pad还是
: dual core，那四核t3已经是比2核1.8G好不少了．如果你有数据,欢迎共享．如果没有
: 用过clover trail的板子, 又没有真实数据challenge上面的测试结果，你还是把自己
: 的怀疑留给自己，别象那个美国教练一样，用牵强的理由怀疑自己不想面对的事实.
| z*n
发帖数: 2893 | 46 我恐怕要给你绕晕了，
clover trail双核1.8GHz,
和双核同频的ARM比:
同是1.8G, 单线程1.2 vs. 1.14, atom胜出；
同是双核1.8G, throughput, 1.54 vs. 1.14, atom胜出;
和四核t3比,（四核的t3做不到1.8G，你总不能自己乘linear系数算吧？）
单线程，1.2 vs. 0.86, atom胜出
双核和四核比throughput: 1.54 vs. 1.25, 还是atom胜出...
这不是atom完胜是啥？单核比你单核快,两个核比你四个核throughput还高.
明年Intel 20nm/4核/OOE的atom就出来了,你上8核的ARM和人家比?
帮忙
5%.
折扣
【在 l******n 的大作中提到】
: 你还真搞笑. 这个引用我最先给你的. 而且数据显示得很清楚, 如果你看不懂我就再帮忙
: 一下. 单核部分:
: S4(1.5G) 1.00 1.00
: Dual-Core A9(1.8G) 1.14 1.14/(1.8/1.5)=0.95
: T3(1.3G) 0.86 0.86/(1.3/1.5)=0.99
: Z2760 1.20 1.20/(1.8/1.5)=1.00
: 这个你也好意思叫完胜么. 而且就算是你一直津津乐道的1.20vs1.14, 差别是多少, 5%.
: 你自己去看看spec官网的测试数据, 同样的cpu, 同样的硬件平台, report的测试结果
: 差个5%简直就是太正常的事情了. 要是用gcc编译的话, 比icc编译的结果差20-30%也不
: 稀奇, 这也就是我为啥一开始就说用新atom跑老x86应用的话, 表现要比这个结果打折扣
| l******n
发帖数: 1683 | 47
1.2跟1.14差别是多少, 5%. 我上面说的很清楚, 你自己也可以去看看spec cpu测试
的官网. 同样cpu同样硬件平台, 测试结果差5%根本就啥都不是
clover trail的规格是双核四线程。超线程这个事情,按照intel自己官方的说法, 15-
20%
的性能加成.
先搞清我们比较的对象是啥, 新atom vs arm a9. 既然这样, 当然首先就是要统一频率.
举个简单例子, 新的频率比较低的ivy bridge的i5-3210M肯定跑不过老的频率较高的
sandy bridge的i5-2540M. 你难道也要得出结论说sandy bridge架构完胜ivy bridge.
而且这个throughout的测试我前面也一再说了, 4核这种东东目前对于个人用户的意义
只是跑分. 一句话, 单核性能怎么提高都不为过, 堆核的话堆来堆去就是忽悠.
A15架构的ARM马上就已经发布了, 至于4核的atom, 在有足够的软件支持之前, who
care?
【在 z*n 的大作中提到】
: 我恐怕要给你绕晕了，
: clover trail双核1.8GHz,
: 和双核同频的ARM比:
: 同是1.8G, 单线程1.2 vs. 1.14, atom胜出；
: 同是双核1.8G, throughput, 1.54 vs. 1.14, atom胜出;
: 和四核t3比,（四核的t3做不到1.8G，你总不能自己乘linear系数算吧？）
: 单线程，1.2 vs. 0.86, atom胜出
: 双核和四核比throughput: 1.54 vs. 1.25, 还是atom胜出...
: 这不是atom完胜是啥？单核比你单核快,两个核比你四个核throughput还高.
: 明年Intel 20nm/4核/OOE的atom就出来了,你上8核的ARM和人家比?
| z*n
发帖数: 2893 | 48 你一直在说A9, 然后拿频率最高的和clover trail比单线程benchmark, 拿throughput
最高的4核(还乘上系数假设能做到同频)比throughput, 就这么比还比不过clover
trail. 问题是你频率快就做不了四核... 无论双核还是四核的总有一项远远不如
clover trail.
这还是CPU intensive的测试, 要是上访存测试, 或者开GPU的时候做同样的spec_int测
试早就被atom不知道甩到哪里去了.
ATOM和i5比确实是蜗牛, 不过这蜗牛比ARM还是要快的. ARM的特色是功耗, 非要和别人
比性能是找死.
率.
【在 l******n 的大作中提到】
:
: 1.2跟1.14差别是多少, 5%. 我上面说的很清楚, 你自己也可以去看看spec cpu测试
: 的官网. 同样cpu同样硬件平台, 测试结果差5%根本就啥都不是
: clover trail的规格是双核四线程。超线程这个事情,按照intel自己官方的说法, 15-
: 20%
: 的性能加成.
: 先搞清我们比较的对象是啥, 新atom vs arm a9. 既然这样, 当然首先就是要统一频率.
: 举个简单例子, 新的频率比较低的ivy bridge的i5-3210M肯定跑不过老的频率较高的
: sandy bridge的i5-2540M. 你难道也要得出结论说sandy bridge架构完胜ivy bridge.
: 而且这个throughout的测试我前面也一再说了, 4核这种东东目前对于个人用户的意义
| l******n
发帖数: 1683 | 49 俺一直关注的只是单核, 明明你是看单核性能差不多非要再拉一个throughout的数据去
凑数. 多核的事情, 俺一直反复说的是双核有用, 4核或者更多没用. 估计你要说了,
z2670不就是个双核的cpu么, 但是问题是这是个双核四线程的cpu, 而spec int_rate
的测试规则是用户可以自行跑多少个线程, 怎么跑通量高就怎么跑, 所以那个数据指
定是同时跑4线程的结果. 这种东西对于个人用户也就是跑分有用.
另外网上已经有一些基于A15的Exynos 5250的测试结果出来了, 相比A9提升巨大. atom
好不容易性能上追上了A9, 但是一转眼就又只能在别人后面吃灰了.
throughput
【在 z*n 的大作中提到】
: 你一直在说A9, 然后拿频率最高的和clover trail比单线程benchmark, 拿throughput
: 最高的4核(还乘上系数假设能做到同频)比throughput, 就这么比还比不过clover
: trail. 问题是你频率快就做不了四核... 无论双核还是四核的总有一项远远不如
: clover trail.
: 这还是CPU intensive的测试, 要是上访存测试, 或者开GPU的时候做同样的spec_int测
: 试早就被atom不知道甩到哪里去了.
: ATOM和i5比确实是蜗牛, 不过这蜗牛比ARM还是要快的. ARM的特色是功耗, 非要和别人
: 比性能是找死.
:
: 率.
| z*n
发帖数: 2893 | 50 你有一个习惯总是凭空认定一个东西,谁告诉你四核没用了, 随便开个task manager自
己看看系统里面有多少进程在运行, 或者你随便开个browser打开个复杂点的网站, 看
看四核上的CPU usage是多少, 你真认为会永远<50%? throughput是衡量CPU最大计算能
力的指标, 同样双核同频的CPU, 性能差30%还不是完败? 而且我们还没有真正上测访存
的benchmark...
A15现在根本没有4核的实现, ARM自己也认为能耗过高, 高频的被建议用在arm server
上, 1.5G之下的建议在移动方案中使用. A15据说比同频A9快40%, t4预期是Q2/2013.
而明年Intel根据roadmap也会有新的基于22nm的atom, 32nm->22nm应当有质的不同, 十
分期待新一代atom的性能参数. 换言之, A15和新一代atom是明年的事情了, 两者可能
差半年, 等产品出来后再讨论不迟.
讨论这么半天, 我希望你能有个结论这代的atom性能比A9强, 从那测试数据来看, 快5-
30%.
atom
【在 l******n 的大作中提到】
: 俺一直关注的只是单核, 明明你是看单核性能差不多非要再拉一个throughout的数据去
: 凑数. 多核的事情, 俺一直反复说的是双核有用, 4核或者更多没用. 估计你要说了,
: z2670不就是个双核的cpu么, 但是问题是这是个双核四线程的cpu, 而spec int_rate
: 的测试规则是用户可以自行跑多少个线程, 怎么跑通量高就怎么跑, 所以那个数据指
: 定是同时跑4线程的结果. 这种东西对于个人用户也就是跑分有用.
: 另外网上已经有一些基于A15的Exynos 5250的测试结果出来了, 相比A9提升巨大. atom
: 好不容易性能上追上了A9, 但是一转眼就又只能在别人后面吃灰了.
:
: throughput
| | | l******n
发帖数: 1683 | 51 倒, task manager里面有多少进程都拿出来了. 好把, 俺刚才查看了一下我的本本, 一
共有146个进程在跑. 那就这样吧, 假设两个cpu, 同样架构, 1个64核(恩, 才64个, 还
远小于146个), 主频只有300M, 一个只有双核, 主频3G. 64核的保证内存带宽和核间对
cache的设计都没问题, thoughout的话是双核的3.2倍, 你会选择哪个?
browser的话, 俺经常开50+的tab, 在这个双核的机器上俺还真没怎么见过cpu usage>
50%过.
而且spec int_rate的测试里面差30%还真不算啥. gcc和icc带来的性能差异就足以填平
这个30%的坑.
双核的A15已经随着google新的chromebook发布了, 主频是1.7G. 而chromebook现在已经
是可以pre-order了. 至于4核的A15, 还是我之前说的, 对于个人用户, who care?
server
【在 z*n 的大作中提到】
: 你有一个习惯总是凭空认定一个东西,谁告诉你四核没用了, 随便开个task manager自
: 己看看系统里面有多少进程在运行, 或者你随便开个browser打开个复杂点的网站, 看
: 看四核上的CPU usage是多少, 你真认为会永远<50%? throughput是衡量CPU最大计算能
: 力的指标, 同样双核同频的CPU, 性能差30%还不是完败? 而且我们还没有真正上测访存
: 的benchmark...
: A15现在根本没有4核的实现, ARM自己也认为能耗过高, 高频的被建议用在arm server
: 上, 1.5G之下的建议在移动方案中使用. A15据说比同频A9快40%, t4预期是Q2/2013.
: 而明年Intel根据roadmap也会有新的基于22nm的atom, 32nm->22nm应当有质的不同, 十
: 分期待新一代atom的性能参数. 换言之, A15和新一代atom是明年的事情了, 两者可能
: 差半年, 等产品出来后再讨论不迟.
| z*n
发帖数: 2893 | 52 我猜你是想说A9双核应当是A9里面最好的了,从那测试结果看,单线程比同频同核的atom
慢5% (1.14 vs. 1.20), throughput慢35% (1.14vs.1.54). 争论4核有没有用是主观问
题,慢5-35%的事实你应当承认.我没工夫和你抬杠, 你只要承认ATOM性能比A9好就行了.
你那编译器猜测需要事实证据, 否则用你自己的话说就是空口说白话. 和那美国教练
怀疑中国游泳吃药一个性质。
这边30%性能不算什么，那边却在吹A15，问题是A15也就比A9快40%.还有你说跑
photoshop / office慢? 你这一边说比双核更多没用, 一边又在说CPU不够，你到底
想说啥？
俺孩子最喜欢上youtube开一堆mario的video, 一个tab一个，来回看着玩, 要不你试
试CPU usage, 不用50+, 十个就成.
A15现在没有4核的产品,告诉你了4核t4要明年Q2. 到时候22nm的ATOM也就差不多出来了
,据说
是4核OOE, 估计下一代就不是5-35%的性能区别了.
已经
【在 l******n 的大作中提到】
: 倒, task manager里面有多少进程都拿出来了. 好把, 俺刚才查看了一下我的本本, 一
: 共有146个进程在跑. 那就这样吧, 假设两个cpu, 同样架构, 1个64核(恩, 才64个, 还
: 远小于146个), 主频只有300M, 一个只有双核, 主频3G. 64核的保证内存带宽和核间对
: cache的设计都没问题, thoughout的话是双核的3.2倍, 你会选择哪个?
: browser的话, 俺经常开50+的tab, 在这个双核的机器上俺还真没怎么见过cpu usage>
: 50%过.
: 而且spec int_rate的测试里面差30%还真不算啥. gcc和icc带来的性能差异就足以填平
: 这个30%的坑.
: 双核的A15已经随着google新的chromebook发布了, 主频是1.7G. 而chromebook现在已经
: 是可以pre-order了. 至于4核的A15, 还是我之前说的, 对于个人用户, who care?
| l******n
发帖数: 1683 | 53 编译器哪个完全就是常识, 你有点这方面的common sense好不好. 既然你喜欢数据, 那
我就好人做到底, 随便给你show两个:
http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060
http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060
gcc 4.1的int_rate2000的成绩是85.9, 而icc 9.1的成绩是115. 而且其实甚至不同版本
的icc的成绩间都可能差异巨大. 提这个很简单, 已有的x86应用有多少是用icc充分编译
优化的, 又有多少是针对clover trail编译优化的. 所以测试里面在编译优化得到的
benefit, 在实际使用是要打折扣的.
而A15 vs A9很简单, 不需要重新对程序重新编译优化, 直接就有显著的性能提高. 此
40%更彼30%当然完全不是一回事情.
CPU性能够不够, 我重复了很多遍, 不介意再重新说一次, 对于个人用户, 对于mobile
设备,迫切需要提高的是单核性能, 堆多核的话4核及4核以上是完全没有意义的. 如果
你还是不听不明白的话, 那我就那你说的"你这一边说比双核更多没用, 一边又在说CPU
不够"解释一下, CPU不够说的是单核性能不够. 前面的帖子我也给你举个例子了, 给你
一个64核的300M的CPU, 和一个双核的3G的CPU. 正常人都该知道选啥. CPU性能不够不
是光靠堆核心就能解决的.
atom
了.
~
~
~
~
~
~
【 】 Ctrl-Q 求救 状态 [插入][3,1][ ][ ] 时间【Sat Oct 20 12:39】
http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060
atom
了.
【在 z*n 的大作中提到】
: 我猜你是想说A9双核应当是A9里面最好的了,从那测试结果看,单线程比同频同核的atom
: 慢5% (1.14 vs. 1.20), throughput慢35% (1.14vs.1.54). 争论4核有没有用是主观问
: 题,慢5-35%的事实你应当承认.我没工夫和你抬杠, 你只要承认ATOM性能比A9好就行了.
: 你那编译器猜测需要事实证据, 否则用你自己的话说就是空口说白话. 和那美国教练
: 怀疑中国游泳吃药一个性质。
: 这边30%性能不算什么，那边却在吹A15，问题是A15也就比A9快40%.还有你说跑
: photoshop / office慢? 你这一边说比双核更多没用, 一边又在说CPU不够，你到底
: 想说啥？
: 俺孩子最喜欢上youtube开一堆mario的video, 一个tab一个，来回看着玩, 要不你试
: 试CPU usage, 不用50+, 十个就成.
| l******n
发帖数: 1683 | 54 我觉得你真应该补习一下测试方面的基本知识. 俺没说intel cheat. 俺说的一直都是
spec测试成绩跟编译优化关系非常大. 编译优化本来就是spec cpu测试规则内允许的
事情. 而只所以找的是06年的测试, 原因很简单:
1. 估计你不到知道的是你之前一直引用的spec int和int_rate的数据其实都是CPU2000
的测试, 而不是CPU2006的测试.
2. ICC vs GCC的性能之争早就盖棺定论. 所以之后的spec测试里面, 你会看到所有用
intel的CPU的系统, 编译器通通都是ICC. 估计你又要问数据了, 好吧, 我好人做到底
给你个intel的官方页面吧:
http://software.intel.com/en-us/intel-composer-xe#details
我觉得吧, 如果你都不知道编译优化对于SPEC测试的重要性的话, 我觉得我真的没必要
再跟你在这浪费时间了.
【在 z*n 的大作中提到】
: 我猜你是想说A9双核应当是A9里面最好的了,从那测试结果看,单线程比同频同核的atom
: 慢5% (1.14 vs. 1.20), throughput慢35% (1.14vs.1.54). 争论4核有没有用是主观问
: 题,慢5-35%的事实你应当承认.我没工夫和你抬杠, 你只要承认ATOM性能比A9好就行了.
: 你那编译器猜测需要事实证据, 否则用你自己的话说就是空口说白话. 和那美国教练
: 怀疑中国游泳吃药一个性质。
: 这边30%性能不算什么，那边却在吹A15，问题是A15也就比A9快40%.还有你说跑
: photoshop / office慢? 你这一边说比双核更多没用, 一边又在说CPU不够，你到底
: 想说啥？
: 俺孩子最喜欢上youtube开一堆mario的video, 一个tab一个，来回看着玩, 要不你试
: 试CPU usage, 不用50+, 十个就成.
| s********a
发帖数: 328 | 55 我的双核AtomN470 Google CR-48慢得不能忍受， 对atom实在没有好感，搞来搞去，
连480P的youtube也就只能勉强放
比一代ipad都差得太远了单核1G Arm都差太远了， 哎
对atom完全没有好感。
memory
统.
【在 z*n 的大作中提到】
: N450那是上上代的ATOM了, 中间还有N2600/2800.
: 我记得我给你解释过这一代ARM的问题了. ARM的问题是访存代宽不够, 多核或者memory
: intensive的测试不行. 比如nvidia的t3, 一旦屏幕刷新时GPU开始工作, CPU访存立刻
: 歇菜, 那时候四个核一起上还不如平时一个核快. 相比之下ATOM是更加balanced的系统.
: 跑win8/winrt, 信我一句, 我两种板子都摸过, ATOM的win8 tablet在性能上完胜t3的
: winrt, 很明显能肉眼看出区别的那种.
: 从理论上讲, winRT/win32是native API在sandbox里运行, 会比javascript快, 是和
: ndk一个量级的. 如果同样的计算, 在android上用javascript实现, 和用winrt/xaml的
: metro实现比, 理论上讲类似native code的metro app应当快不少.
: 如果拿atom和i3/i5比那确实是蜗牛, 没有办法干真正的编译/视频转换之类的重活, 但
| z*n
发帖数: 2893 | 56 我记得回答过类似问题了.
HD video decoding比的是GPU, 单核1G ARM软解HD也是没戏的．N470有on-die GPU, 支
持硬解720P, 你遇到的问题更可能是chromebook自己没有利用硬件解压. 我记得你跟我
说过打开了硬件加速选项, 那这只可能是chormeos缺功能或者有bug.
clover trail板子上win8 IE10上面播放youtube是硬解，这个我特意摸过,没啥好担心
的.如果发现哪个browser不支持使用硬件解压, 第一件事情是换browser.
【在 s********a 的大作中提到】
: 我的双核AtomN470 Google CR-48慢得不能忍受， 对atom实在没有好感，搞来搞去，
: 连480P的youtube也就只能勉强放
: 比一代ipad都差得太远了单核1G Arm都差太远了， 哎
: 对atom完全没有好感。
:
: memory
: 统.
| l******n
发帖数: 1683 | 57 我觉得俺没啥好跟你说的了. 你完全对这方面缺乏common sense. 不要说atom了, 就连
AMD的CPU, 大家都知道用ICC要显著的快.
不过我还是再做点好人吧, 你自己随便找个机器装个ICC, 然后敲个icc -help, 就可以
找到对编译选项-xSSSE3_ATOM的说明如下:
May generate MOVBE instructions for Intel processors,
depending on the setting of option -minstruction.
May also generate Intel(R) SSSE3, SSE3, SSE2, and SSE
instructions for Intel processors. Optimizes for the
Intel(R) Atom(TM) processor and Intel(R) Centrino(R)
Atom(TM) Processor Technology.
其他的东东你还是自己去做点功课吧.
and
Atom
【在 z*n 的大作中提到】
: 我记得回答过类似问题了.
: HD video decoding比的是GPU, 单核1G ARM软解HD也是没戏的．N470有on-die GPU, 支
: 持硬解720P, 你遇到的问题更可能是chromebook自己没有利用硬件解压. 我记得你跟我
: 说过打开了硬件加速选项, 那这只可能是chormeos缺功能或者有bug.
: clover trail板子上win8 IE10上面播放youtube是硬解，这个我特意摸过,没啥好担心
: 的.如果发现哪个browser不支持使用硬件解压, 第一件事情是换browser.
| l******n
发帖数: 1683 | 58 考, 你不会仔细看看呀. 最后一句话:
Optimizes for the Intel(R) Atom(TM) processor and Intel(R) Centrino(R)
Atom(TM) Processor Technology.
而且其实这个说不说都无所谓, 即使是AMD家的CPU, ICC性能也要远强于GCC.
这些东西都是common sense, 要真不懂, 查查资料或者随便找个人问问.
【在 z*n 的大作中提到】
: 我记得回答过类似问题了.
: HD video decoding比的是GPU, 单核1G ARM软解HD也是没戏的．N470有on-die GPU, 支
: 持硬解720P, 你遇到的问题更可能是chromebook自己没有利用硬件解压. 我记得你跟我
: 说过打开了硬件加速选项, 那这只可能是chormeos缺功能或者有bug.
: clover trail板子上win8 IE10上面播放youtube是硬解，这个我特意摸过,没啥好担心
: 的.如果发现哪个browser不支持使用硬件解压, 第一件事情是换browser.
| l******n
发帖数: 1683 | 59 把你的文章放出来. GCC vs ICC, 很多编译优化直接缺失, 而且最重要的, ICC在代码
的vectorization方面领先GCC实在太多了. 没这个东西, 那些SSE呀, 就全是摆设了.
CPU
【在 z*n 的大作中提到】
: 我记得回答过类似问题了.
: HD video decoding比的是GPU, 单核1G ARM软解HD也是没戏的．N470有on-die GPU, 支
: 持硬解720P, 你遇到的问题更可能是chromebook自己没有利用硬件解压. 我记得你跟我
: 说过打开了硬件加速选项, 那这只可能是chormeos缺功能或者有bug.
: clover trail板子上win8 IE10上面播放youtube是硬解，这个我特意摸过,没啥好担心
: 的.如果发现哪个browser不支持使用硬件解压, 第一件事情是换browser.
| l******n
发帖数: 1683 | 60 俺说的这两件事都是常识性的东西. 任何一个有这方面基本经验的不会有不认同的.
而且返个头来, 要说严谨的话, intel自己就应该publish测试的基本信息. 很简单,
把结果提交到官网的数据库中就行. 要不的话, 俺自己凭空编出几个数字来, 那算啥.
【在 z*n 的大作中提到】
: 我记得回答过类似问题了.
: HD video decoding比的是GPU, 单核1G ARM软解HD也是没戏的．N470有on-die GPU, 支
: 持硬解720P, 你遇到的问题更可能是chromebook自己没有利用硬件解压. 我记得你跟我
: 说过打开了硬件加速选项, 那这只可能是chormeos缺功能或者有bug.
: clover trail板子上win8 IE10上面播放youtube是硬解，这个我特意摸过,没啥好担心
: 的.如果发现哪个browser不支持使用硬件解压, 第一件事情是换browser.
| | | z*n
发帖数: 2893 | 61 这个事实其实俺同意，这不是第三方数字，并不中立.
其实争来争去就是上下一些百分点的事情，我也认为这代最快ATOM和最快的ARM A9性能
差不多, 我认为atom稍快, 你认为arm稍块, 里里外外其实也没差多少.
你其实自己也明白你没有数据, 是在猜测．
没劲,我是要停了,５分钟后删贴.
【在 l******n 的大作中提到】
: 俺说的这两件事都是常识性的东西. 任何一个有这方面基本经验的不会有不认同的.
: 而且返个头来, 要说严谨的话, intel自己就应该publish测试的基本信息. 很简单,
: 把结果提交到官网的数据库中就行. 要不的话, 俺自己凭空编出几个数字来, 那算啥.
| a********m
发帖数: 15480 | 62 icc自动使用vectorization的地方有多少？优化的时候还是要专门找出瓶颈手工写sse
或者其他simd代码吧。不过gcc为了通用估计有些地方不敢过分优化。
【在 l******n 的大作中提到】
: 把你的文章放出来. GCC vs ICC, 很多编译优化直接缺失, 而且最重要的, ICC在代码
: 的vectorization方面领先GCC实在太多了. 没这个东西, 那些SSE呀, 就全是摆设了.
:
: CPU
| z*n
发帖数: 2893 | 63 我的理解是要用特殊的decorator, 或者openMP什么的.
其他的bbt, pogo大家都在做, 我其实觉得ICC那百分之二三十的gain是扯蛋.
sse
【在 a********m 的大作中提到】
: icc自动使用vectorization的地方有多少？优化的时候还是要专门找出瓶颈手工写sse
: 或者其他simd代码吧。不过gcc为了通用估计有些地方不敢过分优化。
| l******n
发帖数: 1683 | 64 用得很多了. 现在优化手工写汇编代码意义不大了, 不是很有经验的人写出来的代码基本
会比编译器编译出来的慢, 而且会慢很多. 把代码写成编译器能理解的样子就好了.
sse
【在 a********m 的大作中提到】
: icc自动使用vectorization的地方有多少？优化的时候还是要专门找出瓶颈手工写sse
: 或者其他simd代码吧。不过gcc为了通用估计有些地方不敢过分优化。
| l******n
发帖数: 1683 | 65 扯不扯蛋你自己随便找个机器测试一下就知道了. 整点性能大家差距稍微小点, 浮点的
话经常就不仅仅是百分之20-30了. 极端情况差几十倍的都有.
【在 z*n 的大作中提到】
: 我的理解是要用特殊的decorator, 或者openMP什么的.
: 其他的bbt, pogo大家都在做, 我其实觉得ICC那百分之二三十的gain是扯蛋.
:
: sse
| z*n
发帖数: 2893 | 66 我其实很怀疑这数据,通常MS的做法是用Intel的IPP, 然后自己做BBT/POGO, 如果真能
有这么大差别，别说是20%-30%, 能有5%,也早就用ICC了.
我猜测Intel那数据中最多的性能提升是从IPP来的．
【在 l******n 的大作中提到】
: 扯不扯蛋你自己随便找个机器测试一下就知道了. 整点性能大家差距稍微小点, 浮点的
: 话经常就不仅仅是百分之20-30了. 极端情况差几十倍的都有.
| h***l
发帖数: 244 | 67 现在的人怎么了，老是想着二手价格买一手的新货。
【在 s**********e 的大作中提到】
: RT
| s********a
发帖数: 328 | 68 chromebook这么一体化做软件， 都搞不出来， 这东西真的那么难吗？而且看youtube
这么常用的功能。。。
我是从一个最终用户的角度看的， 至少跟ipad一代比， chromebook的N470+chrome在
正常使用：看视频， 看网页， 速度真的不能接受。 后来装了Ubuntu也是一个样。
【在 z*n 的大作中提到】
: 我记得回答过类似问题了.
: HD video decoding比的是GPU, 单核1G ARM软解HD也是没戏的．N470有on-die GPU, 支
: 持硬解720P, 你遇到的问题更可能是chromebook自己没有利用硬件解压. 我记得你跟我
: 说过打开了硬件加速选项, 那这只可能是chormeos缺功能或者有bug.
: clover trail板子上win8 IE10上面播放youtube是硬解，这个我特意摸过,没啥好担心
: 的.如果发现哪个browser不支持使用硬件解压, 第一件事情是换browser.
| l******n
发帖数: 1683 | 69 你太搞了, 你知道BBT/POGO部分优化的是啥么, 对性能的提高是啥量级么.
【在 z*n 的大作中提到】
: 我其实很怀疑这数据,通常MS的做法是用Intel的IPP, 然后自己做BBT/POGO, 如果真能
: 有这么大差别，别说是20%-30%, 能有5%,也早就用ICC了.
: 我猜测Intel那数据中最多的性能提升是从IPP来的．
| z*n
发帖数: 2893 | 70 我觉得技术上没有什么好解释的了,软解HD和硬解放在一起比是不会得出任何有用的信
息的.
你下面的问题应当是去咨询chromeOS. 这东西确实没啥难的.
youtube
【在 s********a 的大作中提到】
: chromebook这么一体化做软件， 都搞不出来， 这东西真的那么难吗？而且看youtube
: 这么常用的功能。。。
: 我是从一个最终用户的角度看的， 至少跟ipad一代比， chromebook的N470+chrome在
: 正常使用：看视频， 看网页， 速度真的不能接受。 后来装了Ubuntu也是一个样。
| | | z*n
发帖数: 2893 | 71 ...搞得神秘西西的, BBT/POGO都是针对特定scenario的优化, 需要运行想优化的
scenario train的，这是个搞系统的都明白，你当是宝啊．
我和你说了是intel的IPP给力．
【在 l******n 的大作中提到】
: 你太搞了, 你知道BBT/POGO部分优化的是啥么, 对性能的提高是啥量级么.
| l******n
发帖数: 1683 | 72 我看你是把它当个宝吧. BBT/POGO主要是通过收集程序运行中的数据去改善分支预测和
相关的问题. 对于大部分的应用来说上不上，性能提升不大(<5%吧). 你在哪强调MS用
自己的BBT/POGO, 其实就跟富士通去炫耀iphone/ipad都是我们装出来的差不多.
【在 z*n 的大作中提到】
: ...搞得神秘西西的, BBT/POGO都是针对特定scenario的优化, 需要运行想优化的
: scenario train的，这是个搞系统的都明白，你当是宝啊．
: 我和你说了是intel的IPP给力．
| a********m
发帖数: 15480 | 73 不好说。有些地方必须要手写，当然不一定要写汇编。写的时候编译器都给一些原语调
用，这个gcc也有。
skia图形库的sse和其他平台的simd代码都是要手写的，不是靠编译选项。simd有不少
限制，比如前后都需要至少16字节对齐还有溢出位怎么用，这个编译时不可能保证，
sse没写过但是看过skia里面的sse代码也是必须手工处理对齐。
俺同意icc优化更好，但是俺觉得simd这块能靠编译器自动优化的东西比较少。
基本
【在 l******n 的大作中提到】
: 用得很多了. 现在优化手工写汇编代码意义不大了, 不是很有经验的人写出来的代码基本
: 会比编译器编译出来的慢, 而且会慢很多. 把代码写成编译器能理解的样子就好了.
:
: sse
| z*n
发帖数: 2893 | 74 你恐怕中文理解有问题, 我的意见是BBT/POGO可互换意味着各家做的区别不大, 用
Intel的IPP说明这部分是不可替代的.
这里有个例子说你的5%是拍脑袋. 明显是要看用来优化什么程序.
http://msdn.microsoft.com/en-us/library/aa289170(v=VS.71).aspx
要不你给我个5%的事实出处?
【在 l******n 的大作中提到】
: 我看你是把它当个宝吧. BBT/POGO主要是通过收集程序运行中的数据去改善分支预测和
: 相关的问题. 对于大部分的应用来说上不上，性能提升不大(<5%吧). 你在哪强调MS用
: 自己的BBT/POGO, 其实就跟富士通去炫耀iphone/ipad都是我们装出来的差不多.
| l******n
发帖数: 1683 | 75 手工写当然理论上总是可以得到更好的性能, 如果写的人足够牛的话. 字节对齐这种编译
器早就能处理了. 而且你看见的很多汇编代码, 很多都是先编译器得到, 然后再做微调
的.
其实你用ICC编译的时候, 打开vec-report, 就能看到到底能自动优化的loop有多少了.
【在 a********m 的大作中提到】
: 不好说。有些地方必须要手写，当然不一定要写汇编。写的时候编译器都给一些原语调
: 用，这个gcc也有。
: skia图形库的sse和其他平台的simd代码都是要手写的，不是靠编译选项。simd有不少
: 限制，比如前后都需要至少16字节对齐还有溢出位怎么用，这个编译时不可能保证，
: sse没写过但是看过skia里面的sse代码也是必须手工处理对齐。
: 俺同意icc优化更好，但是俺觉得simd这块能靠编译器自动优化的东西比较少。
:
: 基本
| l******n
发帖数: 1683 | 76 你的图表里面不是很清楚么, MS自己的数据, intel x86, specint提升是6%, specfp是
4%. 对于大部分程序来说不就是<5%的性能差别么.
而且BBT/POGO各家做的区别不大有啥意思, 这根本就不是影响编译器性能的核心部分.
就好比大家都卖汽车, 你说我们家的汽车除了发动机和变速箱, 别的都跟别人家的差
不多, 这个有啥意义.
【在 z*n 的大作中提到】
: 你恐怕中文理解有问题, 我的意见是BBT/POGO可互换意味着各家做的区别不大, 用
: Intel的IPP说明这部分是不可替代的.
: 这里有个例子说你的5%是拍脑袋. 明显是要看用来优化什么程序.
: http://msdn.microsoft.com/en-us/library/aa289170(v=VS.71).aspx
: 要不你给我个5%的事实出处?
| z*n
发帖数: 2893 | 77 看来你是非要纠缠下去了.
那文章说的是：
＂The current implementation of PGO has proven to be extremely effective in
getting real-world performance. For example, we've seen 30%+ improvement on
large real-world applications such as Microsoft® SQL Server, and 4-15%
gains on the SPEC benchmarks (depending on the architecture). See Figure 7
for performance speedup of PGO over the best static compilation setting (
Link Time Code Generation) using the SPEC benchmarks.＂
SQL>30%, 图表里六组数据只有一个数据点是4%, 两个在5-10%,三个>10%,这能被用来
支持你那一般<5%的结论？
我再问你一遍, 你那<5%是不是自己拍脑袋猜的, 不是给个引用．
.
【在 l******n 的大作中提到】
: 你的图表里面不是很清楚么, MS自己的数据, intel x86, specint提升是6%, specfp是
: 4%. 对于大部分程序来说不就是<5%的性能差别么.
: 而且BBT/POGO各家做的区别不大有啥意思, 这根本就不是影响编译器性能的核心部分.
: 就好比大家都卖汽车, 你说我们家的汽车除了发动机和变速箱, 别的都跟别人家的差
: 不多, 这个有啥意义.
| l******n
发帖数: 1683 | 78 SQL只是一个单独应用. 图中的CPU, IA2是个严重依赖编译优化的CPU, 体系结构和指令集
也都完全不一样. 而且关键在于visual c++本来就是个性能比icc差很多的编译器. 60分
的学生提高5分跟90分的学生提高5分完全就不是一回事请.
要说证据, 很简单, 随便去浏览一个spec官网上面report的结果. spec的测试结果分
base和peak, base的话是不允许做PGO优化的, peak的话则没有任何限制, 所以在
report peak值的时候, PGO肯定都是试过的, 而且有些的确有prove, 但是你自己
看看结果, 大部分情况下, 不是所有的peak的编译选项都打开了PGO的, 而且打开
了PGO的不少prove也很少.
in
on
【在 z*n 的大作中提到】
: 看来你是非要纠缠下去了.
: 那文章说的是：
: ＂The current implementation of PGO has proven to be extremely effective in
: getting real-world performance. For example, we've seen 30%+ improvement on
: large real-world applications such as Microsoft® SQL Server, and 4-15%
: gains on the SPEC benchmarks (depending on the architecture). See Figure 7
: for performance speedup of PGO over the best static compilation setting (
: Link Time Code Generation) using the SPEC benchmarks.＂
: SQL>30%, 图表里六组数据只有一个数据点是4%, 两个在5-10%,三个>10%,这能被用来
: 支持你那一般<5%的结论？
| z*n
发帖数: 2893 | 79 这不是我的问题, 我问的是你所说的POGO优化<5%的事实依据, 我已经给你数据说明这
不是事实, 你的论据在哪里?
是不是你拍脑袋出来的, 能不能正面回答？
我有问题的是你下面的言论, 能不能给一下数字的出处? 你的大部分应用的sample是
什么?怎么得出的结论？
令集
60分
【在 l******n 的大作中提到】
: 我看你是把它当个宝吧. BBT/POGO主要是通过收集程序运行中的数据去改善分支预测和
: 相关的问题. 对于大部分的应用来说上不上，性能提升不大(<5%吧). 你在哪强调MS用
: 自己的BBT/POGO, 其实就跟富士通去炫耀iphone/ipad都是我们装出来的差不多.
| l******n
发帖数: 1683 | 80 我不跟你说了么, 随便去打开一个spec的测试结果. 你要懒的话, 我就随便给你一个,
最近post的E5-2450的测试结果, int和fp:
http://www.spec.org/cpu2006/results/res2012q4/cpu2006-20120917-
http://www.spec.org/cpu2006/results/res2012q4/cpu2006-20120917-
怎么读数据就不用我再教了吧.
【在 z*n 的大作中提到】
: 这不是我的问题, 我问的是你所说的POGO优化<5%的事实依据, 我已经给你数据说明这
: 不是事实, 你的论据在哪里?
: 是不是你拍脑袋出来的, 能不能正面回答？
: 我有问题的是你下面的言论, 能不能给一下数字的出处? 你的大部分应用的sample是
: 什么?怎么得出的结论？
:
: 令集
: 60分
| | | l******n
发帖数: 1683 | 81 俺估计你是看不懂原始数据...
【在 z*n 的大作中提到】
: 这不是我的问题, 我问的是你所说的POGO优化<5%的事实依据, 我已经给你数据说明这
: 不是事实, 你的论据在哪里?
: 是不是你拍脑袋出来的, 能不能正面回答？
: 我有问题的是你下面的言论, 能不能给一下数字的出处? 你的大部分应用的sample是
: 什么?怎么得出的结论？
:
: 令集
: 60分
| z*n
发帖数: 2893 | 82 我觉得你不应当回避问题，你怎样从spec推到大部分应用?
即便你给的数据也有问题, 46.7 vs. 43.4 , 7.6%...
【在 l******n 的大作中提到】
: 我不跟你说了么, 随便去打开一个spec的测试结果. 你要懒的话, 我就随便给你一个,
: 最近post的E5-2450的测试结果, int和fp:
: http://www.spec.org/cpu2006/results/res2012q4/cpu2006-20120917-
: http://www.spec.org/cpu2006/results/res2012q4/cpu2006-20120917-
: 怎么读数据就不用我再教了吧.
| l******n
发帖数: 1683 | 83 俺说了你看不懂数据你还不承认. spec int有12个应用, 6个应用没PGO啥事, 其他上了
PGO的, 只有4个性能提升超过了5%, fp方面, 17个应用, 还是只有6个上来PGO, 其中
也只有4个性能提升超过了5%. 而且性能的提升还不只来源于PGO. 总计一下, 29个应用
, 其中21个性能提升不超过5%. 这不是大部分是啥.
至于从spec推倒大部分应用, 你该了解了解SPEC测试是干嘛的, 虽然总可能有各种各样
的问题.
【在 z*n 的大作中提到】
: 我觉得你不应当回避问题，你怎样从spec推到大部分应用?
: 即便你给的数据也有问题, 46.7 vs. 43.4 , 7.6%...
| z*n
发帖数: 2893 | 84 你这是回避问题, 你如何得出的＂大部分应用"？ 除了spec你的例证在哪里？
即便你的spec读法也有问题, 里面第一个测试就是近20%的gain, 最后总分+7.6%. 如
何支持你那<5%的论点？
你的读法可以继续深入到spec里面每一个function, 我相信PGO对于"大部分"function
的优化也是<5%, 即便function不行, 可以继续深入到每一行.... 整个spec就是一个
应用, 从你的数据看优化结果是7.6%, 这是反例.
【在 l******n 的大作中提到】
: 俺说了你看不懂数据你还不承认. spec int有12个应用, 6个应用没PGO啥事, 其他上了
: PGO的, 只有4个性能提升超过了5%, fp方面, 17个应用, 还是只有6个上来PGO, 其中
: 也只有4个性能提升超过了5%. 而且性能的提升还不只来源于PGO. 总计一下, 29个应用
: , 其中21个性能提升不超过5%. 这不是大部分是啥.
: 至于从spec推倒大部分应用, 你该了解了解SPEC测试是干嘛的, 虽然总可能有各种各样
: 的问题.
| l******n
发帖数: 1683 | 85 你太搞笑了. 先搞搞清楚SPEC CPU测试是干啥的.
SPEC's goal is to establish, maintain and endorse a standardized set of
relevant benchmarks for computer systems. Although no one set of tests
can fully characterize overall system performance, SPEC believes that
the user community benefits from objective tests which can serve as a
common reference point.
而且现在这个就是业界标准. 你要觉得你更牛那我也没啥办法
再说读数据, 俺给你说得清楚, int测试12个应用, 只有4个peak跟base的差别大于5%,
当然你看的第一个就是. 浮点的话就更这样, 17个应用只有4个peak跟base差别大于5%.
俺前面原话说的是在大部分应用里面, 差别<5%, 有啥问题.
function
【在 z*n 的大作中提到】
: 你这是回避问题, 你如何得出的＂大部分应用"？ 除了spec你的例证在哪里？
: 即便你的spec读法也有问题, 里面第一个测试就是近20%的gain, 最后总分+7.6%. 如
: 何支持你那<5%的论点？
: 你的读法可以继续深入到spec里面每一个function, 我相信PGO对于"大部分"function
: 的优化也是<5%, 即便function不行, 可以继续深入到每一行.... 整个spec就是一个
: 应用, 从你的数据看优化结果是7.6%, 这是反例.
| z*n
发帖数: 2893 | 86 是你在狡辩. spec是一个应用, 你其他的实例在什么地方.
我和你说了你那种分开看的做法是荒谬的, 继续这种思路完全可得出绝大部分情况下任
何优化方法都是无效的. 你只要往下继续看scenario level/function level/line
level, 任何一个应用不可能每一个scenario/function/line都能被优化, 从微观看"绝
大部分"是没法优化的. spec测试你给的数据是优化后分数上升7.6%, 不支持你那<5%的
结论.
你应当正面回答, 你这"大多数应用" 的结论的论据是什么, spec +7.6%, SQL +30%, 你
是不是拍脑袋? 反例在哪里?
,
%.
【在 l******n 的大作中提到】
: 你太搞笑了. 先搞搞清楚SPEC CPU测试是干啥的.
: SPEC's goal is to establish, maintain and endorse a standardized set of
: relevant benchmarks for computer systems. Although no one set of tests
: can fully characterize overall system performance, SPEC believes that
: the user community benefits from objective tests which can serve as a
: common reference point.
: 而且现在这个就是业界标准. 你要觉得你更牛那我也没啥办法
: 再说读数据, 俺给你说得清楚, int测试12个应用, 只有4个peak跟base的差别大于5%,
: 当然你看的第一个就是. 浮点的话就更这样, 17个应用只有4个peak跟base差别大于5%.
: 俺前面原话说的是在大部分应用里面, 差别<5%, 有啥问题.
| l******n
发帖数: 1683 | 87 ... 我觉得你实在是太搞了. SPEC不是一个应用, SPEC是啥, 我前面的帖子里面有, 要
是还不明白, 上官网看看或者google搜搜都可以. 你能不能先补习补习点基础知识之后
再出来讨论.
【在 z*n 的大作中提到】
: 是你在狡辩. spec是一个应用, 你其他的实例在什么地方.
: 我和你说了你那种分开看的做法是荒谬的, 继续这种思路完全可得出绝大部分情况下任
: 何优化方法都是无效的. 你只要往下继续看scenario level/function level/line
: level, 任何一个应用不可能每一个scenario/function/line都能被优化, 从微观看"绝
: 大部分"是没法优化的. spec测试你给的数据是优化后分数上升7.6%, 不支持你那<5%的
: 结论.
: 你应当正面回答, 你这"大多数应用" 的结论的论据是什么, spec +7.6%, SQL +30%, 你
: 是不是拍脑袋? 反例在哪里?
:
: ,
| z*n
发帖数: 2893 | 88 你正面回答就那么难么？ 我在问你除了spec这个应用, 你的＂大多数"<5%的应用还
有啥？
spec这个应用我再说一遍总体提高了7.6%, 你非要每行看过去当然是"大多数"没有优化
提高
, 这和我们讨论的问题无关.
【在 l******n 的大作中提到】
: ... 我觉得你实在是太搞了. SPEC不是一个应用, SPEC是啥, 我前面的帖子里面有, 要
: 是还不明白, 上官网看看或者google搜搜都可以. 你能不能先补习补习点基础知识之后
: 再出来讨论.
| l******n
发帖数: 1683 | 89 What is SPEC?
SPEC is the Standard Performance Evaluation Corporation. SPEC is a non-profi
t organization whose members include computer hardware vendors, software com
panies, universities, research organizations, systems integrators, publisher
s and consultants. SPEC's goal is to establish, maintain and endorse a stand
ardized set of relevant benchmarks for computer systems. Although no one set
of tests can fully characterize overall system performance, SPEC believes t
hat the user community benefits from objective tests which can serve as a co
mmon reference point.
在简单点说, SPEC根本就不是你反复说的一个应用. 当然他需要最后用一个数值来综合
刻画测试的结果.
【在 z*n 的大作中提到】
: 你正面回答就那么难么？ 我在问你除了spec这个应用, 你的＂大多数"<5%的应用还
: 有啥？
: spec这个应用我再说一遍总体提高了7.6%, 你非要每行看过去当然是"大多数"没有优化
: 提高
: , 这和我们讨论的问题无关.
| z*n
发帖数: 2893 | 90 你还是在回避问题, 我是问你那"大多数"应用<5%的结论除了spec你还有没有其他的论
据.
就是个yes/no的问题.
你是不是应当承认你引用的spec结果, 优化后+7.6%?
你会有1000个理由说明为什么你认为spec就是大多数应用, 但这是你主观观点, 我没有
兴趣.
和你说了用你的思路, 能推出绝大多数优化方法对绝大多数的应用都没作用, 这种推理
方法有问题.
profi
com
publisher
stand
set
t
co
【在 l******n 的大作中提到】
: What is SPEC?
: SPEC is the Standard Performance Evaluation Corporation. SPEC is a non-profi
: t organization whose members include computer hardware vendors, software com
: panies, universities, research organizations, systems integrators, publisher
: s and consultants. SPEC's goal is to establish, maintain and endorse a stand
: ardized set of relevant benchmarks for computer systems. Although no one set
: of tests can fully characterize overall system performance, SPEC believes t
: hat the user community benefits from objective tests which can serve as a co
: mmon reference point.
: 在简单点说, SPEC根本就不是你反复说的一个应用. 当然他需要最后用一个数值来综合
| | | l******n
发帖数: 1683 | 91 靠... 这个东西不是我认为. SPEC系列测试都是业界标准. 你要有意见觉得他们做的都
是垃圾, 哪我就没啥好说的了.
【在 z*n 的大作中提到】
: 你还是在回避问题, 我是问你那"大多数"应用<5%的结论除了spec你还有没有其他的论
: 据.
: 就是个yes/no的问题.
: 你是不是应当承认你引用的spec结果, 优化后+7.6%?
: 你会有1000个理由说明为什么你认为spec就是大多数应用, 但这是你主观观点, 我没有
: 兴趣.
: 和你说了用你的思路, 能推出绝大多数优化方法对绝大多数的应用都没作用, 这种推理
: 方法有问题.
:
: profi
| z*n
发帖数: 2893 | 92 你还是在回避问题, 你的"大多数应用" 指的是什么? 除了spec还有什么论据?
能不能正面回答？
我没说spec是垃圾, 我说spec是一个应用, 这个应用优化后+7.6%. 如果非要看每一行
是不是
优化起作用, 我同意你的看法＂绝大多数"行都没作用.
【在 l******n 的大作中提到】
: 靠... 这个东西不是我认为. SPEC系列测试都是业界标准. 你要有意见觉得他们做的都
: 是垃圾, 哪我就没啥好说的了.
| l******n
发帖数: 1683 | 93 我反复说得很清楚了, SPEC不是一个应用而是一组应用. SPEC的goal就是要用这一组应
用综合起来代表整个系统的CPU性能. 而且现在大家也都认可它的想法和选取的应用的
代表性. 简而言之, 说CPU性能, SPEC已经足够.
【在 z*n 的大作中提到】
: 你还是在回避问题, 你的"大多数应用" 指的是什么? 除了spec还有什么论据?
: 能不能正面回答？
: 我没说spec是垃圾, 我说spec是一个应用, 这个应用优化后+7.6%. 如果非要看每一行
: 是不是
: 优化起作用, 我同意你的看法＂绝大多数"行都没作用.
| z*n
发帖数: 2893 | 94 你还是在回避问题. 你是不是承认你的"大多数应用"其实就是spec?
你是不是也应当承认spec跑分优化后+7.6%?
我只需要你对上面事实的承认, 你我如何解读留给自己, 没有必要取得一致.
你反复强调的观点是spec就是大多数应用, 你在反复重复这一主观观点. 我不认同但我
认为
你的主观观点已经well received, 没有必要再强调了.
我的观点是只有看总体提高是有意义的. 任何一个应用能优化的部分是小部分, 往应用
内部看一定会得到优化对于"大部分"模块不起作用的结论. 我相信我的观点你也明白,
我没有强求你
同意, 建议咱们搁置各自的主观观点. 只要对于客观事实有共识, 咱们就可以打住了.
【在 l******n 的大作中提到】
: 我反复说得很清楚了, SPEC不是一个应用而是一组应用. SPEC的goal就是要用这一组应
: 用综合起来代表整个系统的CPU性能. 而且现在大家也都认可它的想法和选取的应用的
: 代表性. 简而言之, 说CPU性能, SPEC已经足够.
| l******n
发帖数: 1683 | 95 我也觉得俺跟你这样胡搅难缠的没啥好说的了. 事实很清楚, 29个测试其中至少有21个
上PGO优化之后的提高<5%, 你要搅我也没办法.
【在 z*n 的大作中提到】
: 你还是在回避问题. 你是不是承认你的"大多数应用"其实就是spec?
: 你是不是也应当承认spec跑分优化后+7.6%?
: 我只需要你对上面事实的承认, 你我如何解读留给自己, 没有必要取得一致.
: 你反复强调的观点是spec就是大多数应用, 你在反复重复这一主观观点. 我不认同但我
: 认为
: 你的主观观点已经well received, 没有必要再强调了.
: 我的观点是只有看总体提高是有意义的. 任何一个应用能优化的部分是小部分, 往应用
: 内部看一定会得到优化对于"大部分"模块不起作用的结论. 我相信我的观点你也明白,
: 我没有强求你
: 同意, 建议咱们搁置各自的主观观点. 只要对于客观事实有共识, 咱们就可以打住了.
| z*n
发帖数: 2893 | 96 我感觉你恐怕没有读明白我的问题, 或者就是在回避问题.
我没工夫和呢纠缠你的主观观点, 对于下面客观事实问题, 你有没有疑问? 没疑问我
认为你就是同意了, ok?
你的"大多数应用"<5%的结论的论据就是spec．除了spec, 你没有其他例证．
你引用的那spec跑分优化后+7.6%．
【在 l******n 的大作中提到】
: 我也觉得俺跟你这样胡搅难缠的没啥好说的了. 事实很清楚, 29个测试其中至少有21个
: 上PGO优化之后的提高<5%, 你要搅我也没办法.
| l******n
发帖数: 1683 | 97 同学, 我说了, 先搞明白SPEC测试的是啥. 比如整点方面12个测试:
400.perlbench C PERL Programming Language
401.bzip2 C Compression
403.gcc C C Compiler
429.mcf C Combinatorial Optimization
445.gobmk C Artificial Intelligence: go
456.hmmer C Search Gene Sequence
458.sjeng C Artificial Intelligence: chess
462.libquantum C Physics: Quantum Computing
464.h264ref C Video Compression
471.omnetpp C++ Discrete Event Simulation
473.astar C++ Path-finding Algorithms
483.xalancbmk C++ XML Processing
看懂了没, 这不是一个应用, 而是选取了12个最有代表性的整点的应用. 每个都是
单独的测试, 可以使用各自独立的编译优化选项和库函数.
【在 z*n 的大作中提到】
: 我感觉你恐怕没有读明白我的问题, 或者就是在回避问题.
: 我没工夫和呢纠缠你的主观观点, 对于下面客观事实问题, 你有没有疑问? 没疑问我
: 认为你就是同意了, ok?
: 你的"大多数应用"<5%的结论的论据就是spec．除了spec, 你没有其他例证．
: 你引用的那spec跑分优化后+7.6%．
| z*n
发帖数: 2893 | 98 我已经反复和你说了你这如何看spec分数的观点已经well received, 我不认同．
你能不能正面回答我的问题? 都是不涉及主观解读的客观事实, 你有没有异意？
你如果不提出异意或者扯其他的东西, 我是不是可以认为你认可下述事实?
发信人: zjn (严禁灌水), 信区: PDA
标 题: Re: PRO 要是卖499 就会爆火吧
发信站: BBS 未名空间站 (Sun Oct 21 22:42:40 2012, 美东)
我感觉你恐怕没有读明白我的问题, 或者就是在回避问题.
我没工夫和呢纠缠你的主观观点, 对于下面客观事实问题, 你有没有疑问? 没疑问我
认为你就是同意了, ok?
你的"大多数应用"<5%的结论的论据就是spec．除了spec, 你没有其他例证．
你引用的那spec跑分优化后+7.6%．
【在 l******n 的大作中提到】
: 同学, 我说了, 先搞明白SPEC测试的是啥. 比如整点方面12个测试:
: 400.perlbench C PERL Programming Language
: 401.bzip2 C Compression
: 403.gcc C C Compiler
: 429.mcf C Combinatorial Optimization
: 445.gobmk C Artificial Intelligence: go
: 456.hmmer C Search Gene Sequence
: 458.sjeng C Artificial Intelligence: chess
: 462.libquantum C Physics: Quantum Computing
: 464.h264ref C Video Compression
| l******n
发帖数: 1683 | 99 我觉得你这就是胡搅难缠了. 我一直的观点是PGO对于大部分应用性能提升<5%. 你要我
给你证据, 我就给了你SPEC的INT和FP的测试. SPEC的结果很清楚的摆在哪, 70%+的应用
PGO的提升都<5%. 当然70%够不够大多数那是另外一个问题.
这个问题我觉得可以到这打住了. 你对这方面的common sense严重缺乏, 跟你说话基本
就是地球人在跟火星人对话.
【在 z*n 的大作中提到】
: 我已经反复和你说了你这如何看spec分数的观点已经well received, 我不认同．
: 你能不能正面回答我的问题? 都是不涉及主观解读的客观事实, 你有没有异意？
: 你如果不提出异意或者扯其他的东西, 我是不是可以认为你认可下述事实?
: 发信人: zjn (严禁灌水), 信区: PDA
: 标 题: Re: PRO 要是卖499 就会爆火吧
: 发信站: BBS 未名空间站 (Sun Oct 21 22:42:40 2012, 美东)
: 我感觉你恐怕没有读明白我的问题, 或者就是在回避问题.
: 我没工夫和呢纠缠你的主观观点, 对于下面客观事实问题, 你有没有疑问? 没疑问我
: 认为你就是同意了, ok?
: 你的"大多数应用"<5%的结论的论据就是spec．除了spec, 你没有其他例证．
| z*n
发帖数: 2893 | 100 你还是选择回避回答事实问题. 我再重复一遍, 你对于下面两个事实有没有意见?
"
你的"大多数应用"<5%的结论的论据就是spec．除了spec, 你没有其他例证．
你引用的那spec跑分优化后+7.6%．
"
和你说了你的解读是主观的, 你我在主观解读spec上有不同意见, 我们应当搁置. 你不
能因为这个人身攻击我. 我的观点很清楚, 那个spec整体优化提高7.6%, 其实是反面例
证. 我现在不想和你争这些观点问题, 很明显和你说不明白. 你不需要不停的纠缠这些
观点. 我们能做到对于facts有共识, 对于opinions有争议就不错了.
应用
【在 l******n 的大作中提到】
: 我觉得你这就是胡搅难缠了. 我一直的观点是PGO对于大部分应用性能提升<5%. 你要我
: 给你证据, 我就给了你SPEC的INT和FP的测试. SPEC的结果很清楚的摆在哪, 70%+的应用
: PGO的提升都<5%. 当然70%够不够大多数那是另外一个问题.
: 这个问题我觉得可以到这打住了. 你对这方面的common sense严重缺乏, 跟你说话基本
: 就是地球人在跟火星人对话.
| | | l******n
发帖数: 1683 | 101 我回答得很明确. 而且即使按照你的解读方式, 整点总分是+7.6%, 但是浮点总分还是只
有+4.3%. 何况peak跟base之间的差别还不仅仅只是PGO.
而且关键你的解读就是错的, 好比我说2012年相比2011年大多数人收入增长不到5%, 然
后你非要跟我说数据统计说平均收入增长了6%, 然后说我说的不对. 这不两码事么.
【在 z*n 的大作中提到】
: 你还是选择回避回答事实问题. 我再重复一遍, 你对于下面两个事实有没有意见?
: "
: 你的"大多数应用"<5%的结论的论据就是spec．除了spec, 你没有其他例证．
: 你引用的那spec跑分优化后+7.6%．
: "
: 和你说了你的解读是主观的, 你我在主观解读spec上有不同意见, 我们应当搁置. 你不
: 能因为这个人身攻击我. 我的观点很清楚, 那个spec整体优化提高7.6%, 其实是反面例
: 证. 我现在不想和你争这些观点问题, 很明显和你说不明白. 你不需要不停的纠缠这些
: 观点. 我们能做到对于facts有共识, 对于opinions有争议就不错了.
:
| z*n
发帖数: 2893 | 102 我们是不是可以得到如下fact statements,
1, 你用来支持你"大多数应用"<5%的论据是spec, 除此之外没有例证
2, 那引用的spec跑分优化后+7.6%
我希望你明确回答, 我说过了你的观点已经well received, 没有必要重复了.
true or false?
是只
【在 l******n 的大作中提到】
: 我回答得很明确. 而且即使按照你的解读方式, 整点总分是+7.6%, 但是浮点总分还是只
: 有+4.3%. 何况peak跟base之间的差别还不仅仅只是PGO.
: 而且关键你的解读就是错的, 好比我说2012年相比2011年大多数人收入增长不到5%, 然
: 后你非要跟我说数据统计说平均收入增长了6%, 然后说我说的不对. 这不两码事么.
| l******n
发帖数: 1683 | 103 1. spec测试是业界标准, 有这个就足够了.
2. 只是int部分 还是总分 而且还不仅仅是PGO部分的贡献.
反过来, 我也问问你看这些是不是fact.
1. 12个代表性整点应用, 至少8个PGO帮助不大(<5%)
2. 17个代表性浮点应用, 至少13个PGO帮助不大(<5%)
3. 总体来说, 至少21/29=70%+的应用PGO帮助不大(<5%)
ture or false?
【在 z*n 的大作中提到】
: 我们是不是可以得到如下fact statements,
: 1, 你用来支持你"大多数应用"<5%的论据是spec, 除此之外没有例证
: 2, 那引用的spec跑分优化后+7.6%
: 我希望你明确回答, 我说过了你的观点已经well received, 没有必要重复了.
: true or false?
:
: 是只
| g*g
发帖数: 6908 | 104 楼太高了
pro不是用i5吗？怎么这么热烈讨论起atom vs arm了？不过还是有些有用的信息，不错 | z*n
发帖数: 2893 | 105 ＂有这个就足够了＂是你的观点，我没有问你对于spec的观点, 那问题是你是不是只有
这一个例证, 是不是?
我没工夫和你纠缠你那唯一的例证是不是能证明你的观点．咱们先放下你这一个例证代
表所有应用的推理错误问题．
证伪只需要一个反例, 我这个引用有
7个实例，其中6个反例，唯一一个小于<5%的是4%：
http://msdn.microsoft.com/en-us/library/aa289170(v=VS.71).aspx
你还有什么好说的？
【在 l******n 的大作中提到】
: 1. spec测试是业界标准, 有这个就足够了.
: 2. 只是int部分 还是总分 而且还不仅仅是PGO部分的贡献.
: 反过来, 我也问问你看这些是不是fact.
: 1. 12个代表性整点应用, 至少8个PGO帮助不大(<5%)
: 2. 17个代表性浮点应用, 至少13个PGO帮助不大(<5%)
: 3. 总体来说, 至少21/29=70%+的应用PGO帮助不大(<5%)
: ture or false?
| z*n
发帖数: 2893 | 106 WK, 你当我想和他垒楼啊, 我昨天晚上就offer他停住, 还主动offer把前面争论的贴子
删了.
我今天本来在回别人贴子, 这家伙不依不饶的非要抓我和他一起垒.
真TMD的累啊.
【在 g*g 的大作中提到】
: 楼太高了
: pro不是用i5吗？怎么这么热烈讨论起atom vs arm了？不过还是有些有用的信息，不错
|
|
