POPPUR爱换

标题: Linux下Cell 3.2G vs. PPC G5 1.6G对比测试出炉 [打印本页]
作者: Prescott    时间: 2006-11-23 12:06
标题: Linux下Cell 3.2G vs. PPC G5 1.6G对比测试出炉
http://www.geekpatrol.ca/2006/11/playstation-3-performance/

Cell的这个PPE还真是强大阿，居然绝大部分测试性能能输给1.6GHz的PowerPC G5。 :wacko:

这个geekbench有Windows版本阿，大家可以测试一下，看看Cell vs Conroe是什么水准 :D

下载地址：
http://www.geekpatrol.ca/geekbench/#download


PlayStation 3 Performance

On Sunday I saw a clip of Fedora Core 5 for PPC running on the PlayStation 3 over at Kotaku; I’d completely forgotten that Sony was going to make it easy to boot other operating systems on the PlayStation 3!

On Monday I started receiving requests for Geekbench for Linux PPC so people could run it on the PlayStation 3. I managed to get a beta version out last night and while it’s not quite ready for public release yet, one beta tester sent in the results for his PlayStation 3 which I thought I’d share. To give the results some context, I’m going to compare the PlayStation 3 results against one of the first Power Mac G5s running at 1.6GHz.

Setup
      Playstation 3
          o Cell Broadband Engine @ 3.2GHz
          o 256 MB RAM
          o Fedora Core 5
          o Geekbench 2006 (Build 243)

      Power Mac G5
          o PowerPC G5 @ 1.6GHz
          o 1280 MB RAM
          o Fedora Core 4
          o Geekbench 2006 (Build 243)

I’m reporting the baseline score, rather than the raw score, for each test (where 100 is the score a PowerMac G5 1.6GHz running Mac OS X would receive on the same test). As always, higher scores are better.

Results
Overall Score
PlayStation 3   105.2
Power Mac G5 106.9

Integer Performance

Emulate 6502 (single-threaded scalar)
PlayStation 3   42.1
Power Mac G5 73.9

Emulate 6502 (multi-threaded scalar)
PlayStation 3   57.3
Power Mac G5 73.8

Blowfish (single-threaded scalar)
PlayStation 3   118.7
Power Mac G5 107.0

Blowfish (multi-threaded scalar)
PlayStation 3    165.6
Power Mac G5  107.0

bzip2 Compress (single-threaded scalar)
PlayStation 3   89.8
Power Mac G5 162.8

bzip2 Compress (multi-threaded scalar)
PlayStation 3   124.1
Power Mac G5 168.4

bzip2 Decompress (single-threaded scalar)
PlayStation 3   76.6
Power Mac G5 129.9

bzip2 Decompress (multi-threaded scalar)
PlayStation 3   99.5
Power Mac G5 133.1

Floating Point Performance

Mandelbrot (single-threaded scalar)
PlayStation 3   49.0
Power Mac G5 100.0

Mandelbrot (multi-threaded scalar)
PlayStation 3   72.1
Power Mac G5 100.0

Dot Product (single-threaded scalar)
PlayStation 3   120.0
Power Mac G5 100.8

Dot Product (multi-threaded scalar)
PlayStation 3   119.3
Power Mac G5 100.3

JPEG Compress (single-threaded scalar)
PlayStation 3   70.7
Power Mac G5 103.0

JPEG Compress (multi-threaded scalar)
PlayStation 3   94.8
Power Mac G5 103.0

JPEG Decompress (single-threaded scalar)
PlayStation 3   61.6
Power Mac G5 119.0

JPEG Decompress (multi-threaded scalar)
PlayStation 3   72.9
Power Mac G5 119.2

Memory Performance

Read Sequential (single-threaded scalar)
PlayStation 3   51.9
Power Mac G5 116.7

Read Sequential (multi-threaded scalar)
PlayStation 3   56.9
Power Mac G5 116.0

Write Sequential (single-threaded scalar)
PlayStation 3   194.6
Power Mac G5 104.7

Write Sequential (multi-threaded scalar)
PlayStation 3   191.4
Power Mac G5 112.7

Stdlib Allocate (single-threaded scalar)
PlayStation 3    43.4
Power Mac G5  56.4

Stdlib Allocate (multi-threaded scalar)
PlayStation 3   51.2
Power Mac G5 55.6

Stdlib Write (single-threaded scalar)
PlayStation 3    331.5
Power Mac G5  92.7

Stdlib Write (multi-threaded scalar)
PlayStation 3   365.9
Power Mac G5 94.7

Stdlib Copy (single-threaded scalar)
PlayStation 3   64.5
Power Mac G5 63.5

Stdlib Copy (multi-threaded scalar)
PlayStation 3   102.1
Power Mac G5 72.7

Stream Performance

Stream Copy (single-threaded scalar)
PlayStation 3   89.7
Power Mac G5 114.1

Stream Copy (multi-threaded scalar)
PlayStation 3   109.9
Power Mac G5 111.8

Stream Scale (single-threaded scalar)
PlayStation 3   69.2
Power Mac G5 118.3

Stream Scale (multi-threaded scalar)
PlayStation 3   101.4
Power Mac G5 120.1

Stream Add (single-threaded scalar)
PlayStation 3   62.6
Power Mac G5 123.0

Stream Add (multi-threaded scalar)
PlayStation 3   93.2
Power Mac G5 118.0

Stream Triad (single-threaded scalar)
PlayStation 3   62.7
Power Mac G5 122.8

Stream Triad (multi-threaded scalar)
PlayStation 3   102.2
Power Mac G5 118.6


Conclusion

There was a comment on Slashdot last year that made the following assertion about the Cell processor:

    The problem is that though the main CPU is PowerPC-based like current Apple chips, it is stripped down, and the Altivec support will be much lower than in current G5s. Unoptomized, Apple code would run like a G4 on this hardware.

Turns out the comment was right; Cell processor performance is comparable to low-end PowerPC G5 performance (which in turn is comparable to high-end PowerPC G4 performance). I can’t comment on Altivec performance, unfortunately, since Geekbench for Linux PPC doesn’t measure Altivec performance yet.

Geekbench also isn’t able to exploit the eight vector processors on the Cell processor. Any program designed and optimized for the Cell processor should be a lot faster than one designed for a generic processor (like, say, Geekbench). So while the Geekbench results might seem disappointing, keep in mind that Geekbench can’t exercise the PlayStation 3 to its full potential.

[ 本帖最后由 Prescott 于 2006-11-23 12:21 编辑 ]
作者: potomac    时间: 2006-11-23 12:15
提示: 作者被禁止或删除 内容自动屏蔽
作者: 武内空    时间: 2006-11-23 12:19
Playstation 3 游戏机？
Playstation 3
Cell Broadband Engine @ 3.2GHz
256 MB RAM
Fedora Core 5
Geekbench 2006 (Build 243)

Power Mac G5 苹果电脑？
Power Mac G5
PowerPC G5 @ 1.6GHz
1280 MB RAM
Fedora Core 4
Geekbench 2006 (Build 243)
作者: Prescott    时间: 2006-11-23 12:26
随便测测3.6G的P4什么水准。

Geekbench 2006 (build 238).  Email geekbench@geekpatrol.ca with fee

System Information
  Geekbench Version:         Geekbench 2006 (build 238)
  Geekbench Platform:        Windows x86 (32-bit)
  Geekbench Compiler:        Visual C++ 2005
  OS:                        Microsoft Windows XP Professional
  Model:                     INTEL_ D915GEV_
  Motherboard:               Intel Corporation D915GEV
  Processor:                 Genuine Intel(R) CPU 3.60GHz
  Processor ID:              GenuineIntel Family 15 Model 3 Steppin
  Logical Processor Count:   2
  Physical Processor Count:  1
  Processor Frequency:       3600 MHz
  Bus Frequency:             200 MHz
  Memory:                    1014 MB

Integer Performance
  Emulate 6502
    single-threaded scalar   198.4 (rate: 1.0, result: 375.1 MHz)
    multi-threaded scalar    190.0 (rate: 1.0, result: 359.1 MHz)
  Blowfish
    single-threaded scalar   213.3 (rate: 1.0, result: 88.0 MB/sec)
    multi-threaded scalar    213.3 (rate: 1.0, result: 88.0 MB/sec)
  bzip2 Compress
    single-threaded scalar   309.8 (rate: 1.0, result: 48.3 MB/sec)
    multi-threaded scalar    311.8 (rate: 1.0, result: 48.4 MB/sec)
  bzip2 Decompress
    single-threaded scalar   280.0 (rate: 1.0, result: 104.1 MB/sec
    multi-threaded scalar    288.6 (rate: 1.0, result: 103.9 MB/sec

Floating Point Performance
  Mandelbrot
    single-threaded scalar   117.3 (rate: 1.0, result: 831.4 Mflops
    multi-threaded scalar    117.3 (rate: 1.0, result: 831.3 Mflops
  Dot Product
    single-threaded scalar    50.5 (rate: 1.0, result: 260.3 Mflops
    multi-threaded scalar     50.2 (rate: 1.0, result: 260.8 Mflops
    single-threaded vector   149.3 (rate: 8.1, result: 2.1 Gflops)
    multi-threaded vector    148.4 (rate: 8.2, result: 2.1 Gflops)
  JPEG Compress
    single-threaded scalar   138.1 (rate: 1.0, result: 12.8 Mpixels
    multi-threaded scalar    138.2 (rate: 1.0, result: 12.8 Mpixels
  JPEG Decompress
    single-threaded scalar   187.9 (rate: 1.0, result: 31.2 Mpixels
    multi-threaded scalar    181.4 (rate: 1.0, result: 30.1 Mpixels

Memory Performance
  Read Sequential
    single-threaded scalar   262.8 (rate: 1.0, result: 3.3 GB/sec)
    multi-threaded scalar    266.8 (rate: 0.5, result: 1.6 GB/sec)
  Write Sequential
    single-threaded scalar   266.7 (rate: 1.0, result: 2.0 GB/sec)
    multi-threaded scalar    266.1 (rate: 0.5, result: 1022.1 MB/se
  Stdlib Allocate
    single-threaded scalar    83.4 (rate: 1.0, result: 2.9 Mallocs/
    multi-threaded scalar     82.2 (rate: 1.0, result: 2.9 Mallocs/
  Stdlib Write
    single-threaded scalar    98.6 (rate: 1.0, result: 2.5 GB/sec)
    multi-threaded scalar     87.2 (rate: 0.8, result: 2.0 GB/sec)
  Stdlib Copy
    single-threaded scalar   112.0 (rate: 1.0, result: 1.2 GB/sec)
    multi-threaded scalar    117.0 (rate: 1.0, result: 1.2 GB/sec)

Stream Performance
  Stream Copy
    single-threaded scalar   187.2 (rate: 1.0, result: 2.3 GB/sec)
    multi-threaded scalar    188.8 (rate: 1.0, result: 2.4 GB/sec)
    single-threaded vector   182.5 (rate: 1.1, result: 2.5 GB/sec)
    multi-threaded vector    183.3 (rate: 1.1, result: 2.5 GB/sec)
  Stream Scale
    single-threaded scalar   191.8 (rate: 1.0, result: 2.2 GB/sec)
    multi-threaded scalar    192.5 (rate: 1.0, result: 2.3 GB/sec)
    single-threaded vector   176.3 (rate: 1.1, result: 2.4 GB/sec)
    multi-threaded vector    178.6 (rate: 1.1, result: 2.5 GB/sec)
  Stream Add
    single-threaded scalar   192.4 (rate: 1.0, result: 2.5 GB/sec)
    multi-threaded scalar    187.7 (rate: 1.0, result: 2.5 GB/sec)
    single-threaded vector   187.6 (rate: 1.0, result: 2.6 GB/sec)
    multi-threaded vector    186.8 (rate: 1.1, result: 2.7 GB/sec)
  Stream Triad
    single-threaded scalar   190.2 (rate: 1.0, result: 2.5 GB/sec)
    multi-threaded scalar    187.4 (rate: 1.0, result: 2.5 GB/sec)
    single-threaded vector   149.7 (rate: 1.0, result: 2.6 GB/sec)
    multi-threaded vector    148.6 (rate: 1.1, result: 2.6 GB/sec)

Overall Score:   178.1
作者: xeon-pan    时间: 2006-11-23 12:31
比p4还差？:huh: :huh:
作者: HardCoded    时间: 2006-11-23 12:33
呵呵，如我所料，果然是C4级别的通用计算水平，牛啊
作者: hopetoknow2    时间: 2006-11-23 12:36
Ultra 20 M2:   1.8G
    * AMD Dual-Core Opteron 1210
    * 512 MB DDR2-667 (1 DIMM)
    * Windows XP Professional x64 Edition
    * Geekbench 2006 (build 230)

Overall Score:   147.6

Integer Performance
  Emulate 6502
    single-threaded scalar   76.8
    multi-threaded scalar    153.7
  Blowfish
    single-threaded scalar   118.6
    multi-threaded scalar    237.3
  bzip2 Compress
    single-threaded scalar   180.6
    multi-threaded scalar    364.3
  bzip2 Decompress
    single-threaded scalar   140.8
    multi-threaded scalar    300.9

Floating Point Performance
  Mandelbrot
    single-threaded scalar   121.6
    multi-threaded scalar    243.2
  Dot Product
    single-threaded scalar    57.2
    multi-threaded scalar     113.4
  JPEG Compress
    single-threaded scalar   117.9
    multi-threaded scalar    236.2
  JPEG Decompress
    single-threaded scalar   113.2
    multi-threaded scalar    220.6

Memory Performance
  Read Sequential
    single-threaded scalar   150.1
    multi-threaded scalar    108.9
  Write Sequential
    single-threaded scalar   167.0
    multi-threaded scalar    214.4
  Stdlib Allocate
    single-threaded scalar    87.6
    multi-threaded scalar     37.0
  Stdlib Write
    single-threaded scalar    60.6
    multi-threaded scalar     89.4
  Stdlib Copy
    single-threaded scalar   78.2
    multi-threaded scalar    99.4

Stream Performance
  Stream Copy
    single-threaded scalar   141.3
    multi-threaded scalar    168.9
  Stream Scale
    single-threaded scalar   132.5
    multi-threaded scalar    172.9
  Stream Add
    single-threaded scalar   100.8
    multi-threaded scalar    156.5
   Stream Triad
    single-threaded scalar   91
    multi-threaded scalar    153

[ 本帖最后由 hopetoknow2 于 2006-11-23 12:53 编辑 ]
作者: potomac    时间: 2006-11-23 12:38
提示: 作者被禁止或删除 内容自动屏蔽
作者: HardCoded    时间: 2006-11-23 12:39
原帖由 xeon-pan 于 2006-11-23 12:31 发表
比p4还差？:huh: :huh:



:lol: 请CELL先和K7比，然后才有资格和P4比。和Conroe比？那简直就是秒杀
作者: xeon-pan    时间: 2006-11-23 12:42
原帖由 HardCoded 于 2006-11-23 12:39 发表



:lol: 请CELL先和K7比，然后才有资格和P4比。和Conroe比？那简直就是秒杀

你没弄明白我的意思吧....当初sony吹cell比高端p4块100000000000..........00000000000倍的。。。:lol:
作者: HardCoded    时间: 2006-11-23 12:45
原帖由 xeon-pan 于 2006-11-23 12:42 发表

你没弄明白我的意思吧....当初sony吹cell比高端p4块100000000000..........00000000000倍的。。。:lol:



:lol: 我知道，人家还能模拟地球呢
作者: skywalker_hao    时间: 2006-11-23 12:54
Mac Pro (ID 10052)
Overall Score: 383.2
System Information
Metric Value
Geekbench Version Geekbench 2006 (build 242)
Geekbench Platform Mac OS X x86 (64-bit)
Geekbench Compiler GCC 4.0.1 (Apple Computer, Inc. build 5363)
OS Mac OS X (Darwin 8.8.1)
Model Mac Pro
Motherboard MacPro1,1
Processor Intel(R) Xeon(R) CPU 5150 @ 2.66GHz
Processor ID GenuineIntel Family 6 Model 15 Stepping 6
Logical Processor Count 4
Physical Processor Count 4
Processor Frequency 2660 MHz
Bus Frequency 1332 MHz
Memory 8192 MB

Integer Performance
Benchmark Score Rate Result
Emulate 6502
single-threaded scalar 218.4 1.0 412.9 MHz
Emulate 6502
multi-threaded scalar 868.2 4.0 1.6 GHz
Blowfish
single-threaded scalar 205.2 1.0 84.7 MB/sec
Blowfish
multi-threaded scalar 817.6 4.0 337.2 MB/sec
bzip2 Compress
single-threaded scalar 282.2 1.0 44.0 MB/sec
bzip2 Compress
multi-threaded scalar 1057.5 3.7 164.0 MB/sec
bzip2 Decompress
single-threaded scalar 298.2 1.0 110.9 MB/sec
bzip2 Decompress
multi-threaded scalar 1099.4 3.6 396.0 MB/sec

Floating Point Performance
Benchmark Score Rate Result
Mandelbrot
single-threaded scalar 180.0 1.0 1.3 Gflops
Mandelbrot
multi-threaded scalar 718.5 4.0 5.1 Gflops
Dot Product
single-threaded scalar 321.9 1.0 1.7 Gflops
Dot Product
multi-threaded scalar 1110.7 3.5 5.8 Gflops
Dot Product
single-threaded vector 155.9 1.3 2.2 Gflops
Dot Product
multi-threaded vector 507.3 4.4 7.3 Gflops
JPEG Compress
single-threaded scalar 196.8 1.0 18.3 Mpixels/sec
JPEG Compress
multi-threaded scalar 780.2 4.0 72.3 Mpixels/sec
JPEG Decompress
single-threaded scalar 187.4 1.0 31.1 Mpixels/sec
JPEG Decompress
multi-threaded scalar 640.6 3.4 106.2 Mpixels/sec

Memory Performance
Benchmark Score Rate Result
Read Sequential
single-threaded scalar 318.0 1.0 4.0 GB/sec
Read Sequential
multi-threaded scalar 174.4 0.3 1.1 GB/sec
Write Sequential
single-threaded scalar 524.3 1.0 4.0 GB/sec
Write Sequential
multi-threaded scalar 290.4 0.3 1.1 GB/sec
Stdlib Allocate
single-threaded scalar 360.3 1.0 12.7 Mallocs/sec
Stdlib Allocate
multi-threaded scalar 60.6 0.2 2.2 Mallocs/sec
Stdlib Write
single-threaded scalar 132.8 1.0 3.4 GB/sec
Stdlib Write
multi-threaded scalar 215.8 1.5 5.1 GB/sec
Stdlib Copy
single-threaded scalar 260.9 1.0 2.8 GB/sec
Stdlib Copy
multi-threaded scalar 453.2 1.6 4.7 GB/sec

Stream Performance
Benchmark Score Rate Result
Stream Copy
single-threaded scalar 212.7 1.0 2.7 GB/sec
Stream Copy
multi-threaded scalar 358.7 1.7 4.5 GB/sec
Stream Copy
single-threaded vector 204.5 1.0 2.8 GB/sec
Stream Copy
multi-threaded vector 329.2 1.7 4.5 GB/sec
Stream Scale
single-threaded scalar 224.4 1.0 2.6 GB/sec
Stream Scale
multi-threaded scalar 381.2 1.7 4.5 GB/sec
Stream Scale
single-threaded vector 202.9 1.1 2.8 GB/sec
Stream Scale
multi-threaded vector 328.0 1.7 4.5 GB/sec
Stream Add
single-threaded scalar 225.8 1.0 2.9 GB/sec
Stream Add
multi-threaded scalar 360.0 1.7 4.9 GB/sec
Stream Add
single-threaded vector 216.3 1.0 3.0 GB/sec
Stream Add
multi-threaded vector 343.3 1.7 4.9 GB/sec
Stream Triad
single-threaded scalar 225.6 1.0 2.9 GB/sec
Stream Triad
multi-threaded scalar 362.6 1.7 4.9 GB/sec
Stream Triad
single-threaded vector 174.3 1.0 3.0 GB/sec
Stream Triad
multi-threaded vector 276.2 1.7 4.9 GB/sec
:p

[ 本帖最后由 skywalker_hao 于 2006-11-23 12:56 编辑 ]
作者: hopetoknow2    时间: 2006-11-23 12:59
距离 超  级    大
作者: hopetoknow2    时间: 2006-11-23 12:59
再来一次， 超       级                大
作者: Edison    时间: 2006-11-23 13:00
单独1个2 -issue in-order FGMT的PPE跑出来Dot Product就几乎把3-issue OOO SMT的P4踩在脚下了。
作者: z1978    时间: 2006-11-23 13:09
原帖由 Edison 于 2006-11-23 13:00 发表
单独1个2 -issue in-order FGMT的PPE跑出来Dot Product就几乎把3-issue OOO SMT的P4踩在脚下了。


DOT PRODUCT是决定什么呢
作者: Prescott    时间: 2006-11-23 13:12
原帖由 Edison 于 2006-11-23 13:00 发表
单独1个2 -issue in-order FGMT的PPE跑出来Dot Product就几乎把3-issue OOO SMT的P4踩在脚下了。

让x87跑dot product，是不是有些残忍？
当SSE3不存在是不是？Vector之后Cell还不是一样被踩。
(_(

[ 本帖最后由 Prescott 于 2006-11-23 13:14 编辑 ]
作者: Edison    时间: 2006-11-23 13:12
原帖由 z1978 于 2006-11-23 13:09 发表
DOT PRODUCT是决定什么呢

物理运算、图形分析计算都会大量包含dot product。
作者: Edison    时间: 2006-11-23 13:16
原帖由 Prescott 于 2006-11-23 13:12 发表
让x87跑dot product，是不是有些残忍？
当SSE3不存在是不是？Vector之后Cell还不是一样被踩。(_(

你要忽略VMX、SPE的话，为什么不把SSE也忽略掉呢？
作者: FENG950    时间: 2006-11-23 13:17
这个成绩有什么，不过只是PPE的能力反应而已，Cell如果只是一块PPE的用途，那它和别的CPU比也没有任何特别之处了。对比P4的性能，所指当然是某方面的性能比较，当初的宣传是指所有方面都比高端P4快吗？何况这PPE还是一个2发射按序核心，就算C4一级，也都不只2 issue了吧？这里的测试软件，是否有按有序核心作标准进行优化设计了呢？
作者: potomac    时间: 2006-11-23 13:19
提示: 作者被禁止或删除 内容自动屏蔽
作者: Edison    时间: 2006-11-23 13:23
yellow dog出来也不代表什么，我认为要体现CELL的应用特点，必须用EEMBC的Telemark测试才有意义。
作者: Prescott    时间: 2006-11-23 13:26
原帖由 Edison 于 2006-11-23 13:16 发表

你要忽略VMX、PPE的话，为什么不把SSE也忽略掉呢？

区别在于，VMX并不能帮到PPE，PPC中浮点指令已经相当的强悍。而X87太弱，SSE3在浮点性能方面提升巨大。

SPE如果你能用起来，我也不反对拿出来测试阿。我倒是要看看Linux也有了，所谓的开发环境也有了，到底第一款用到SPE的软件什么时候出来。

转这个测试只是用来证明我的预言，Cell整数性能极弱，无法应对主流游戏的高要求。想象一下，一颗比C4还要差一截的主处理器，无论显卡多好，玩游戏是什么感觉。Cell最合适的用途是在蓝光播放机里做解码器，可惜功耗又太高了些。Sony这次绝对要输给MS，光开发的难易程度，两者根本不可同日而语，必然造成游戏资源上的差异。3个PPC核心，无论如何要比一个PPE加7个SPE好用的多得多，真实游戏性能上也决不差于Cell。

[ 本帖最后由 Prescott 于 2006-11-23 13:32 编辑 ]
作者: Prescott    时间: 2006-11-23 13:33
原帖由 Edison 于 2006-11-23 13:23 发表
yellow dog出来也不代表什么，我认为要体现CELL的应用特点，必须用EEMBC的Telemark测试才有意义。

呵呵，EEMBC的telemark又怎么样，Cell照样垫底，不要忘了，EEMBC不许修改源代码的。SPE还是用不上。哈哈
作者: Edison    时间: 2006-11-23 13:37
PPE 是 2-issue，FPU+VMX可以做到12 FLOPS per cycle，P4的两个SSE单元都挂在同一个issue port上，无论怎么撑都是有架构上的缺陷。

这个测试丝毫不能怎么你所谓的CELL整数性能极弱的观点，顶多只能说明CELL其中1/8的PPE如此，试问这里的那个测试是不能改写成适 合 于 SPE跑的？
作者: Edison    时间: 2006-11-23 13:41
原帖由 Prescott 于 2006-11-23 13:33 发表
呵呵，EEMBC的telemark又怎么样，Cell照样垫底，不要忘了，EEMBC不许修改源代码的。SPE还是用不上。哈哈


谁告诉你EEMBC不能修改代码的，你当是SEPC CPU？
单个SPE@3.2GHz的telemark是770，你看看需要多少个Conroe凑一个晶体管数量相当的Cell吧。
作者: Prescott    时间: 2006-11-23 13:42
原帖由 Edison 于 2006-11-23 13:37 发表
PPE 是 2-issue，FPU+VMX可以做到12 FLOPS per cycle，P4的两个SSE单元都挂在同一个issue port上，无论怎么撑都是有架构上的缺陷。

这个测试丝毫不能怎么你所谓的CELL整数性能极弱的观点，顶多只能说明CELL其 ...

那你去改写吧 :lol:

指望SPE提供额外的非多媒体整数能力那完全是在痴人说梦。
作者: Edison    时间: 2006-11-23 13:46
SPE本身就具备native的INT16/INT32整数指令执行能力，说SPE不具备整数指令并且把AI看作只能在PPE上跑本身就是错误的。
作者: HardCoded    时间: 2006-11-23 13:57
呵呵,说到底CELL就是个专用处理器嘛
作者: FENG950    时间: 2006-11-23 14:00
原帖由 HardCoded 于 2006-11-23 13:57 发表
呵呵,说到底CELL就是个专用处理器嘛

在娱乐平台上难道用通吃型的好吗？
作者: hopetoknow2    时间: 2006-11-23 14:00
原帖由 Edison 于 2006-11-23 13:46 发表
SPE本身就具备native的INT16/INT32整数指令执行能力，说SPE不具备整数指令并且把AI看作只能在PPE上跑本身就是错误的。

SPE说不定连像样的动态分支预测都没有！
作者: HardCoded    时间: 2006-11-23 14:01
原帖由 hopetoknow2 于 2006-11-23 14:00 发表

SPE说不定连像样的动态分支预测都没有！



:lol: 哪来的啊
作者: HardCoded    时间: 2006-11-23 14:03
原帖由 FENG950 于 2006-11-23 14:00 发表

在娱乐平台上难道用通吃型的好吗？



呵呵,Conroe怎么样?效能比CELL好,价格比CELL便宜,货源充足.
作者: hopetoknow2    时间: 2006-11-23 14:04
原帖由 Edison 于 2006-11-23 13:37 发表
PPE 是 2-issue，FPU+VMX可以做到12 FLOPS per cycle

VMX是128bit寄存器， 一MAC指令充其量4个FLOPX2， 2-issue如何12 FLOPS的？

PPE的通用性能就是不行
作者: eonhy    时间: 2006-11-23 14:06
似乎这回脸丢大了~~~
作者: potomac    时间: 2006-11-23 14:09
提示: 作者被禁止或删除 内容自动屏蔽
作者: FENG950    时间: 2006-11-23 14:10
原帖由 HardCoded 于 2006-11-23 14:03 发表



呵呵,Conroe怎么样?效能比CELL好,价格比CELL便宜,货源充足.

你从哪方面可以认为Conroe比Cell样样好？比多媒体应用？或是多线程应用？

[ 本帖最后由 FENG950 于 2006-11-23 14:14 编辑 ]
作者: Edison    时间: 2006-11-23 14:15
原帖由 hopetoknow2 于 2006-11-23 14:04 发表
VMX是128bit寄存器， 一MAC指令充其量4个FLOPX2， 2-issue如何12 FLOPS的？
PPE的通用性能就是不行

PPE的FPU在执行单精度算法的时候，可以做到2D FMA，加上4D的VMX FMA，就是12 FLOPS。

NGC时代的Geeko FPU设计和PPE的FPU是类似的，RTW的David T. Wang对此当初也是迷惑不解。
作者: HardCoded    时间: 2006-11-23 14:19
原帖由 FENG950 于 2006-11-23 14:10 发表

你从哪方面可以认为Conroe比Cell好？比多媒体应用？或是多线程应用？



:lol: 呵呵,不排除CELL那种古怪架构在某方面大翻身的可能.

但就指令性能来讲,Conroe可以把他扔出地球.
作者: hopetoknow2    时间: 2006-11-23 14:21
原帖由 Edison 于 2006-11-23 14:15 发表

PPE的FPU在执行单精度算法的时候，可以做到2D FMA，加上4D的VMX FMA，就是12 FLOPS。

个人的观点：
SPE根本就算不上具有分支预测能力，基本是靠软件静态指定的。只是填入BTB。 至于预测功能，搞不好是静态的，单纯的Not Taken或Taken。

而且就算预测对了，也是有3个周期的延迟。
作者: FENG950    时间: 2006-11-23 14:23
原帖由 HardCoded 于 2006-11-23 14:19 发表



:lol: 呵呵,不排除CELL那种古怪架构在某方面大翻身的可能.

但就指令性能来讲,Conroe可以把他扔出地球.

那你也可以换个角度考虑下，在做PS3需要的事情时，Cell可以把Conroe扔出太阳系。

脱离了各自的应用环境来大谈CPU性能，有意义么？
作者: Edison    时间: 2006-11-23 14:23
原帖由 HardCoded 于 2006-11-23 14:19 发表
:lol: 呵呵,不排除CELL那种古怪架构在某方面大翻身的可能.
但就指令性能来讲,Conroe可以把他扔出地球.

在绝大部分游戏应用中，Conroe都不如Cell，例如物理、音频、视频、基于可视化分析的AI等。
作者: lemon_z    时间: 2006-11-23 14:24
是不是测试软件还没有针对cell优化？
作者: Prescott    时间: 2006-11-23 14:27
原帖由 Edison 于 2006-11-23 13:41 发表


谁告诉你EEMBC不能修改代码的，你当是SEPC CPU？
单个SPE@3.2GHz的telemark是770，你看看需要多少个Conroe凑一个晶体管数量相当的Cell吧。

怎么跑起TeleBench来了？你不是开玩笑吧，难道Cell打算退出游戏领域，转战信号处理了？随便找个DSP干这个也比Cell强的多。EMMBC都是嵌入式系统的Benchmark，代码和数据大小都以KB记。

即便是跑TeleBench，一个Conroe 3GHz至少可以相当于3-4个SPE，一个PPC970FX @ 2G都能跑到1058，770很厉害吗？
作者: Edison    时间: 2006-11-23 14:27
从一开始大家都知道SPE是不具备动态分支预测的吧，但是同时也都应该知道SPE是具备128个寄存器以及能够从分支目标开始预取32条指令的branch hint能力。
作者: HardCoded    时间: 2006-11-23 14:30
呵呵,作为一个正统的通用处理器,YY浮点是没什么意思的.

CPU架构的精华都在如何提高指令性能上,这才是体现一个CPU艺术性和先进性的地方.像Conroe这样近乎完美的指令性能,足以让同期任何一款CPU服到五体投地.

至于提高浮点性能,个人兴趣不大.简单叠加计算单元的东西,只要成本控制的住,想提高多少是多少.

呵呵,纯粹个人之见.
作者: Edison    时间: 2006-11-23 14:31
原帖由 Prescott 于 2006-11-23 14:27 发表
怎么跑起TeleBench来了？你不是开玩笑吧，难道Cell打算退出游戏领域，转战信号处理了？随便找个DSP干这个也比Cell强的多。EMMBC都是嵌入式系统的Benchmark，代码和数据大小都以KB记。
即便是跑TeleBench， ...

CELL跑游戏所处理大部分计算其实都是EEMBC针对的嵌入式应用，一个SPE是770，7个就是相当于5390，还没算上PPE。
作者: jgzyinnv    时间: 2006-11-23 14:34
我看不太懂大家的评论,我只想知道现在的PS3装的CELL性能能强过我的扣肉6300么?
作者: Edison    时间: 2006-11-23 14:37
原帖由 jgzyinnv 于 2006-11-23 14:34 发表
我看不太懂大家的评论,我只想知道现在的PS3装的CELL性能能强过我的扣肉6300么?

你需要6300 OC 3GHz + Dual PPU + AISeek Processor才能和CELL比。
作者: Prescott    时间: 2006-11-23 14:41
原帖由 HardCoded 于 2006-11-23 14:30 发表
呵呵,作为一个正统的通用处理器,YY浮点是没什么意思的.

CPU架构的精华都在如何提高指令性能上,这才是体现一个CPU艺术性和先进性的地方.像Conroe这样近乎完美的指令性能,足以让同期任何一款CPU服到五体投地.
...

非常正确，要纯浮点性能是最简单的事情，显卡和ClearSpeed就是典型的例子。如果需要，Conroe再加浮点单元就是，或者SIMD再作长点，搞个512bit的寄存器，这种事情又不是没人做过，有什么意思？

问题是这种浮点性能只能用在HPC领域，信号处理和多媒体中，而且绝大部分时候还不好用。Cell这种异构的东西，简直就是一个Cluster on Chip，想象一下为一个有8台计算机的集群写游戏，让他们并行运行吧。Mission impossible!
作者: Edison    时间: 2006-11-23 14:44
那就看整数性能好了：

作者: Prescott    时间: 2006-11-23 14:44
原帖由 Edison 于 2006-11-23 14:37 发表

你需要6300 OC 3GHz + Dual PPU + AISeek Processor才能和CELL比。

哈哈，国际玩笑。

E6600 + 7900GT绝对能在所有游戏中取得比PS3更好的游戏效果，不信等着瞧。:lol:
作者: Edison    时间: 2006-11-23 14:46
原帖由 Prescott 于 2006-11-23 14:41 发表
非常正确，要纯浮点性能是最简单的事情，显卡和ClearSpeed就是典型的例子。如果需要，Conroe再加浮点单元就是，或者SIMD再作长点，搞个512bit的寄存器，这种事情又不是没人做过，有什么意思？
问题是这种浮 ...

现在的PC上就有APU、AISeek这样的附加卡提供物理、AI加速，为什么就不能把SPE作为这类产品来写程序，难道你真得以为1个CPU就能跑游戏，什么叫mission impossible，你这样的想法就是了。
作者: z1978    时间: 2006-11-23 14:47
prescott 和cho的对话真精彩，虽然我基本都看不懂。
请教一下cho，你觉得以ps3的性能，
装个LINUX当HTPC，播放HDTV等高清视频，
是否可行？
作者: HardCoded    时间: 2006-11-23 14:47
原帖由 Edison 于 2006-11-23 14:23 发表

在绝大部分游戏应用中，Conroe都不如Cell，例如物理、音频、视频、基于可视化分析的AI等。



:loveliness: 我没有这方面的编程经验,所以谈不上真正理解你所说的这些算法应用.

但至少CELL处理你所说的"可视化分析的AI"的性能,不会比Conroe采用传统的方法性能还高吧?
作者: Prescott    时间: 2006-11-23 14:48
原帖由 Edison 于 2006-11-23 14:44 发表
那就看整数性能好了：


同学，理论值没有意义的，PD 945 3.4G无论整数还是浮点理论值都是Athlon64 2G的将近4倍。你要不要跑个游戏看看哪个厉害？不服那就两个PD 945，怎么样？那就是快8倍的性能了，有用吗？跑信号处理，多媒体处理，还有你所谓的AI，物理处理APU，两个PD 945不知道要杀Athlon64 2G不知道多少个来回，但是现实的游戏呢？

不要忘记SMP共享内存的系统，写程序要比Cell这种异构系统，各自使用本地内存的诡异系统容易不知道多少倍，把游戏多线程化大家都觉得头疼，你以为给Cell那种诡异的系统写程序那么容易？是个程序员都要疯掉。

[ 本帖最后由 Prescott 于 2006-11-23 14:55 编辑 ]
作者: HardCoded    时间: 2006-11-23 14:53
原帖由 Edison 于 2006-11-23 14:44 发表
那就看整数性能好了：




:loveliness: 玩笑了玩笑了,你这里的整数性能应该是指纯数学运算加减乘除的性能吧?这个真的就没意义了.
作者: FENG950    时间: 2006-11-23 14:54
原帖由 HardCoded 于 2006-11-23 14:30 发表
呵呵,作为一个正统的通用处理器,YY浮点是没什么意思的.

CPU架构的精华都在如何提高指令性能上,这才是体现一个CPU艺术性和先进性的地方.像Conroe这样近乎完美的指令性能,足以让同期任何一款CPU服到五体投地.
...

我个人的意见，任何东西的先进和艺术都体现在针对自身环境的适应性上，结果在多大程度上切合设计目标，是最重要的考量。CPU指令是复杂的好，还是简单的好，核心是有序的好还是无序的好，都没有一个定论。即使是RISC也会采用某些复杂功能的指令，按序的核心一样可以有强大的执行效能。CPU单个处理能力越强越好？Blue Gene却可以为了大量的并行采用尽可能的简化设计，你说浮点的叠加很简单，但是现在看来，做到轻松叠加的，却是采用最简单CPU的Blue Gene，其他采用强大而复杂CPU的，硬是叠不出来（有些东西看来是说得容易做的难啊）。任何东西做出来总是有目标的，完不成目标却空口说我什么什么地方先进，有用吗？先进用什么来衡量？
作者: Illuminati    时间: 2006-11-23 14:54
贴个 E6300 @ 2.8 得数据作对比吧


Geekbench 2006 (build 238).  Email geekbench@geekpatrol.ca with feedback.

System Information
  Geekbench Version:         Geekbench 2006 (build 238)
  Geekbench Platform:        Windows x86 (32-bit)
  Geekbench Compiler:        Visual C++ 2005
  OS:                        Microsoft Windows XP Professional
  Model:                     GBT___ GBTUACPI
  Motherboard:               Gigabyte Technology Co., Ltd. 965P-DS4
  Processor:                 Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
  Processor ID:              GenuineIntel Family 6 Model 15 Stepping 6
  Logical Processor Count:   2
  Physical Processor Count:  2
  Processor Frequency:       2800 MHz
  Bus Frequency:             400 MHz
  Memory:                    2046 MB

Integer Performance
  Emulate 6502
    single-threaded scalar   298.6 (rate: 1.0, result: 564.6 MHz)
    multi-threaded scalar    592.0 (rate: 2.0, result: 1.1 GHz)
  Blowfish
    single-threaded scalar   181.5 (rate: 1.0, result: 74.9 MB/sec)
    multi-threaded scalar    361.7 (rate: 2.0, result: 149.2 MB/sec)
  bzip2 Compress
    single-threaded scalar   333.7 (rate: 1.0, result: 52.0 MB/sec)
    multi-threaded scalar    646.5 (rate: 1.9, result: 100.3 MB/sec)
  bzip2 Decompress
    single-threaded scalar   337.1 (rate: 1.0, result: 125.4 MB/sec)
    multi-threaded scalar    671.2 (rate: 1.9, result: 241.8 MB/sec)

Floating Point Performance
  Mandelbrot
    single-threaded scalar   181.9 (rate: 1.0, result: 1.3 Gflops)
    multi-threaded scalar    362.5 (rate: 2.0, result: 2.6 Gflops)
  Dot Product
    single-threaded scalar   119.7 (rate: 1.0, result: 616.6 Mflops)
    multi-threaded scalar    236.3 (rate: 2.0, result: 1.2 Gflops)
    single-threaded vector   246.0 (rate: 5.6, result: 3.5 Gflops)
    multi-threaded vector    487.6 (rate: 11.4, result: 7.0 Gflops)
  JPEG Compress
    single-threaded scalar   218.5 (rate: 1.0, result: 20.3 Mpixels/sec)
    multi-threaded scalar    436.4 (rate: 2.0, result: 40.4 Mpixels/sec)
  JPEG Decompress
    single-threaded scalar   240.7 (rate: 1.0, result: 40.0 Mpixels/sec)
    multi-threaded scalar    470.0 (rate: 1.9, result: 77.9 Mpixels/sec)

Memory Performance
  Read Sequential
    single-threaded scalar   375.7 (rate: 1.0, result: 4.7 GB/sec)
    multi-threaded scalar    112.1 (rate: 0.1, result: 697.0 MB/sec)
  Write Sequential
    single-threaded scalar   291.3 (rate: 1.0, result: 2.2 GB/sec)
    multi-threaded scalar    284.5 (rate: 0.5, result: 1.1 GB/sec)
  Stdlib Allocate
    single-threaded scalar   148.9 (rate: 1.0, result: 5.3 Mallocs/sec)
    multi-threaded scalar     86.1 (rate: 0.6, result: 3.1 Mallocs/sec)
  Stdlib Write
    single-threaded scalar   562.5 (rate: 1.0, result: 14.3 GB/sec)
    multi-threaded scalar    123.0 (rate: 0.2, result: 2.9 GB/sec)
  Stdlib Copy
    single-threaded scalar   210.7 (rate: 1.0, result: 2.3 GB/sec)
    multi-threaded scalar    166.7 (rate: 0.7, result: 1.7 GB/sec)

Stream Performance
  Stream Copy
    single-threaded scalar   239.2 (rate: 1.0, result: 3.0 GB/sec)
    multi-threaded scalar    256.2 (rate: 1.1, result: 3.2 GB/sec)
    single-threaded vector   233.9 (rate: 1.1, result: 3.2 GB/sec)
    multi-threaded vector    244.2 (rate: 1.1, result: 3.3 GB/sec)
  Stream Scale
    single-threaded scalar   258.6 (rate: 1.0, result: 3.0 GB/sec)
    multi-threaded scalar    269.6 (rate: 1.1, result: 3.2 GB/sec)
    single-threaded vector   223.4 (rate: 1.0, result: 3.0 GB/sec)
    multi-threaded vector    232.6 (rate: 1.1, result: 3.2 GB/sec)
  Stream Add
    single-threaded scalar   278.6 (rate: 1.0, result: 3.6 GB/sec)
    multi-threaded scalar    285.0 (rate: 1.1, result: 3.8 GB/sec)
    single-threaded vector   271.7 (rate: 1.0, result: 3.8 GB/sec)
    multi-threaded vector    270.1 (rate: 1.1, result: 3.9 GB/sec)
  Stream Triad
    single-threaded scalar   277.5 (rate: 1.0, result: 3.6 GB/sec)
    multi-threaded scalar    286.8 (rate: 1.1, result: 3.8 GB/sec)
    single-threaded vector   214.5 (rate: 1.0, result: 3.7 GB/sec)
    multi-threaded vector    215.8 (rate: 1.1, result: 3.8 GB/sec)

Overall Score:   291.8
作者: Edison    时间: 2006-11-23 14:57
这还不容易，拿类似3DMARK06那样的CPU test场景跑跑看就知道了，你可以去看看PD 945和K8 2GHz的3DMAR06 CPU Mark差距是多少。

使用SPE来做物理、AI、音频、加密/解密处理，要比分离的多片PPU、AISeek、声卡、DSP容易得多。
作者: Edison    时间: 2006-11-23 15:00
原帖由 HardCoded 于 2006-11-23 14:53 发表
:loveliness: 玩笑了玩笑了,你这里的整数性能应该是指纯数学运算加减乘除的性能吧?这个真的就没意义了.

SPE的整数操作除了你说的算术指令外，还有字符串操作、分支操作等其他所有处理器都具备的整数指令能力。
作者: HardCoded    时间: 2006-11-23 15:03
原帖由 Edison 于 2006-11-23 15:00 发表

SPE的整数操作除了你说的算术指令外，还有字符串操作、分支操作等其他所有处理器都具备的整数指令能力。


每个SPE单独算,然后乘8??
作者: potomac    时间: 2006-11-23 15:05
提示: 作者被禁止或删除 内容自动屏蔽
作者: FENG950    时间: 2006-11-23 15:07
原帖由 HardCoded 于 2006-11-23 15:03 发表


每个SPE单独算,然后乘8??

理论值么，其他对比的CPU一样也是简单的加乘得到的，看看就好。
作者: RacingPHT    时间: 2006-11-23 15:07
提示: 作者被禁止或删除 内容自动屏蔽
作者: Edison    时间: 2006-11-23 15:07
原帖由 HardCoded 于 2006-11-23 15:03 发表
每个SPE单独算,然后乘8??

物理、AI、音频都是有大量可以并行化处理的地方，是可以达到很高的并行度的。
作者: Edison    时间: 2006-11-23 15:12
原帖由 RacingPHT 于 2006-11-23 15:07 发表
Cell是在图像类应用中现在是没有对手的。
但是作为游戏机的主CPU, 我觉得Cho有些神化Cell了。PS3的内存分级太多, 异构处理器也太多, 想起来就很麻烦。
题外话, PC只需要一个Pentium3 + G80就可以获得数百G fl ...

我想我没有神话Cell，上述的发言，更多的是看到一些只是抓住Cell的某几个可以克服的弱点就几乎完全把Cell否定的说法。

G80跑整数操作可能比较呛，CUDA公布后就可以大致了解了。
作者: HardCoded    时间: 2006-11-23 15:16
原帖由 Prescott 于 2006-11-23 14:41 发表

非常正确，要纯浮点性能是最简单的事情，显卡和ClearSpeed就是典型的例子。如果需要，Conroe再加浮点单元就是，或者SIMD再作长点，搞个512bit的寄存器，这种事情又不是没人做过，有什么意思？

问题是这种浮 ...



呵呵,就是嘛.

软件本来就是个复杂的东西, 我真的很难想象CELL程序员疲与应付各种CELL处理单元会是个什么状态.

抛开所谓的理论性能不谈,其实CELL本身就是违背软件大环境的东西,如果硬件不能为开发者提供简单易行的环境,其带来的问题:bug数量,软件工期,开发成本......足以杀死任何一个优秀的软件团队.
作者: potomac    时间: 2006-11-23 15:21
提示: 作者被禁止或删除 内容自动屏蔽
作者: RacingPHT    时间: 2006-11-23 15:22
提示: 作者被禁止或删除 内容自动屏蔽
作者: xiaxiaf    时间: 2006-11-23 15:22
提示: 作者被禁止或删除 内容自动屏蔽
作者: Edison    时间: 2006-11-23 15:24
最简单的方式就是用CPU完成所有的游戏处理，3D图形渲染、音频处理、游戏逻辑、物理计算，这样游戏开发人员只需要掌握一个ISA即可，准备一格画面等半天吧。
作者: RacingPHT    时间: 2006-11-23 15:25
提示: 作者被禁止或删除 内容自动屏蔽
作者: Prescott    时间: 2006-11-23 15:25
和一个非程序员讨论程序编写的难度是一件没有意义的事情。
作者: HardCoded    时间: 2006-11-23 15:26
原帖由 Edison 于 2006-11-23 14:57 发表
这还不容易，拿类似3DMARK06那样的CPU test场景跑跑看就知道了，你可以去看看PD 945和K8 2GHz的3DMAR06 CPU Mark差距是多少。

使用SPE来做物理、AI、音频、加密/解密处理，要比分离的多片PPU、AISeek、声卡、 ...



呵呵,3DMARK06那样的CPU test场景??我怀疑那个测试项目是纯粹为了提高多核心CPU成绩而写的.和你所说的"基于图象分析的AI"应该完全是两回事.

那个CPU test大概就是: 一个bot一个线程,以一块共享的内存数据作为地图,n个bot都会单独地进行碰撞检测运算.所以才会导致那个场景运行如此之慢.
作者: Edison    时间: 2006-11-23 15:27
80%的预测率所有CPU都可以死掉了，幸好CELL还有XDR，不知道Conroe会如何。
作者: Prescott    时间: 2006-11-23 15:29
原帖由 Edison 于 2006-11-23 15:27 发表
80%的预测率所有CPU都可以死掉了，幸好CELL还有XDR，不知道Conroe会如何。

是啊，不知道SPE是怎么读到XDR里边的数据的。麻烦Edson大大给大家描绘一下。

至于分支预测的成功率，如果Cornoe能做到99%，不知道PPE有没有80%，这个测试中Emulate 就是典型的分支多的例子了。看看差距吧。

[ 本帖最后由 Prescott 于 2006-11-23 15:31 编辑 ]
作者: HardCoded    时间: 2006-11-23 15:47
原帖由 potomac 于 2006-11-23 15:21 发表

说的很有道理。

麻烦解释下Xenon中PPU和CELL中PPE的差别。:huh:


http://game.pchome.net/00/05/24/30/?292,,
作者: hopetoknow2    时间: 2006-11-23 15:58
原帖由 Edison 于 2006-11-23 14:27 发表
从一开始大家都知道SPE是不具备动态分支预测的吧，但是同时也都应该知道SPE是具备128个寄存器以及能够从分支目标开始预取32条指令的branch hint能力。

你这里的branch hint是依靠软件来提供静态指示， 又不是能够 同时取分支的两个方向。 取错了，一样是损失很大。
而且， 即使对了也有几个周期的延迟。
作者: Edison    时间: 2006-11-23 15:59
SPE对XDR的存储大家都知道是DMA方式，在流式应用中，DMA方式相当好。

CELL的PPE和XCPU的PPE都是一样的动态分支预测机制，在运行这个测试的时候，XCPU的PPE在这里的仿真器性能表现也是和CELL一样的。

PPE就是一个2 issue、in-order的设计，你给它搭配强大的动态分支预测能力不浪费吗？当年类似架构的Pentium才75%的预测率呢。
作者: hopetoknow2    时间: 2006-11-23 16:04
原帖由 Edison 于 2006-11-23 14:44 发表
那就看整数性能好了：


你这是16bit的整数测试。 还是峰值测试。

根本和通常指的整数性能是两个概念。
一个典型整数应用 Load和Store指令占40%，load数量两倍于store；分支占10-20%； 剩下的一般是ALU指令。  现在游戏在CPU中，跑的整数代码，基本上就是这类型的代码。
作者: Edison    时间: 2006-11-23 16:13
图片没有完全显示，在图片中最右面图柱是int32。

不过SPE的整数乘法只有16 bit，做32bit乘法的时候需要三条16bit乘法+两条32bit加法。

SPE是由pipeline2执行load/store执行，延迟是7个周期，在不相依的情况下，每个周期可以发射一条L/S和一条算术/字符串操作指令。
作者: 单晶硅传奇    时间: 2006-11-23 16:35
不明白，要是AMD弄颗傻龙再加上个X1300集成在一个DIE内，那是不是无论通用性能还是峰值性能都可以把CELL秒杀了:lol:
作者: hopetoknow2    时间: 2006-11-23 16:51
原帖由 Edison 于 2006-11-23 16:13 发表
图片没有完全显示，在图片中最右面图柱是int32。

不过SPE的整数乘法只有16 bit，做32bit乘法的时候需要三条16bit乘法+两条32bit加法。

SPE是由pipeline2执行load/store执行，延迟是7个周期，在不相依的情 ...

而且SPE， 好像连Load buffer/Store buffer也都没有。 Load指令和Store指令的实际执行效率， 恐怕经常Stall
作者: potomac    时间: 2006-11-23 17:01
提示: 作者被禁止或删除 内容自动屏蔽
作者: hopetoknow2    时间: 2006-11-23 17:10
SPE没有本地缓存， 而是RAM。   这是有区别的。

Load buffer/Store buffer和缓存也是不同的东西。
作者: jgzyinnv    时间: 2006-11-23 17:14
原帖由 Edison 于 2006-11-23 14:37 发表

你需要6300 OC 3GHz + Dual PPU + AISeek Processor才能和CELL比。


老大，没那么夸张把？:o  Dual PPU + AISeek Processor什东东啊
作者: Tanknet    时间: 2006-11-23 17:24
其实Cell
主要还是要有好编译器和开发运行库才行
PC上程序 可以用Intel Compiler自动向量化+多线程化

物理运算和图像运算并行度都是很高的,我编计算物理程序,体会颇深
PD 820 512M DDR2 533内存
同一个程序(GSAW-自规避随机行走,1000个粒子2000*2000网格)用VC6编译出来，跑10分钟
用Intel c++ compiler跑1分钟20秒，加速比就是这么高
关键就是IBM能不能开发出强大的编译器来。Cell的编译器开发应该比Intel双核难。


下面内容有争议：
而且Cell犯了和安腾一样的错，只不过没有鹌鹑那么深：把很多不该由编译器干的活交给了编译器。编译器毕竟是死板的东西啊


还有就是楼上人提到的SPE分支预测差，这个我倒觉得无所谓，毕竟对8条线程进行分别的分支预测是很耗晶体管的
软件写BPB？不太可能吧？
每个SPE单元都有本地缓存。

是本地内存，程序员可以访问的快速内存

如果以后显示芯片和CPU集成了，显示芯片还支持多线程，那个CPU的浮点速度一定非常快，可是毕竟Cell是第一个，第一个经常做的很幼稚。

[ 本帖最后由 Tanknet 于 2006-11-23 18:09 编辑 ]
作者: hopetoknow2    时间: 2006-11-23 17:47
EPIC和CELL是两回事情。一个是RISC演生，  一个VLIW演生。

LS所说的东西，他可能自己不知道， 全部可以看成是攻击VLIW。

LS对体系结构极为重大的一个流派VLIW，很不了解， 可以说成是有点不知天外有天了，先学习VLIW， 再回来学习EPIC，不然很难了解什么是IA64。
http://we.pcinlife.com/thread-609496-1-1.html
VLIW是极有价值的体系结构， 虽然搞RISC的仇恨它， 但是...
作者: Tanknet    时间: 2006-11-23 18:11
原帖由 hopetoknow2 于 2006-11-23 17:47 发表
EPIC和CELL是两回事情。一个是RISC演生，  一个VLIW演生。

LS所说的东西，他可能自己不知道， 全部可以看成是攻击VLIW。

LS对体系结构极为重大的一个流派VLIW，很不了解， 可以说成是有点不知天外有天了， ...


请推荐一本关于VLIW和EPIC的书。我看的是很老的书<RISC Architectures> 和<RISC单发射和多发射体系架构>内对VLIW的介绍,可能落后了
作者: Tanknet    时间: 2006-11-23 18:18
原帖由 hopetoknow2 于 2006-11-23 17:47 发表
http://we.pcinlife.com/thread-609496-1-1.html


这里面没有讨论IA64或者VLIW的啊？ 发错连接了？
作者: hopetoknow2    时间: 2006-11-23 18:31
原帖由 Tanknet 于 2006-11-23 18:18 发表

这里面没有讨论IA64或者VLIW的啊？ 发错连接了？

呵呵，只是说VLIW派系也很牛， 居然拿了2次最高荣誉。
咱没有资料啊。 只是重复以前别人教训咱的话。 说咱搞了半天，居然还没发现体系结构世界的另一半"邪恶势力"。
作者: Edison    时间: 2006-11-23 19:19
VLIW的代码尺寸成本很高，SPE那点内存可能塞不了几个VLIW包就爆掉了。
作者: Edison    时间: 2006-11-23 19:42
原帖由 hopetoknow2 于 2006-11-23 16:51 发表
而且SPE， 好像连Load buffer/Store buffer也都没有。 Load指令和Store指令的实际执行效率， 恐怕经常Stall

LS离得这么近，你觉得MOB弄多大合适？
作者: hopetoknow2    时间: 2006-11-23 19:49
原帖由 Edison 于 2006-11-23 19:19 发表
VLIW的代码尺寸成本很高，SPE那点内存可能塞不了几个VLIW包就爆掉了。

处理这个问题，EPIC的寄存器旋转技术，可比原来的VLIW要高明多了。
作者: hopetoknow2    时间: 2006-11-23 19:54
原帖由 Edison 于 2006-11-23 19:42 发表

LS离得这么近，你觉得MOB弄多大合适？

看上去近，但这不算近， 不是说7周期延迟吗?

不少处理器的L1D也很近， 还是需要Load buffer/Store buffer来缓冲，不然冲突停顿的开销很利害。

你以为是Itanium2的1周期延迟啊?还有ALAT猜测机制等等。
作者: Edison    时间: 2006-11-23 20:00
SPE的流水线是in-order的设计，又有128个128bit寄存器，如果把MOB做成Conroe那样成本太高了，性能改善也不见得合理。
作者: potomac    时间: 2006-11-23 20:05
提示: 作者被禁止或删除 内容自动屏蔽
作者: hopetoknow2    时间: 2006-11-23 20:14
原帖由 Edison 于 2006-11-23 20:00 发表
SPE的流水线是in-order的设计，有128个4D SP寄存器，如果把MOB做成Conroe那样成本太高了，性能改善也不见得合理。

对于"典型"整数应用来说，这没什么。 比寄存器数量，Itanium的寄存器够多吧?  猜猜看， Load/Store指令占多少比例? 还是很大的。

SPE最近的存储单元，高延迟，而Load Buffer/Store Buffer缓冲环节如此脆弱， 还有Memory disambig.混叠的时候， 有好戏看了。
作者: hdfeel    时间: 2006-11-24 07:04
spe 的发挥需要牺牲 ppe 的性能，   这种测试 对 pc 不公平， 游戏机是 简单化， 被 sony fan 称做，  专门 优化，  没有 windows 那么臃肿的系统，所以效率 高很多。  sony fan 说 linux 效率比 windows 高很多。 所以 在windows 下 测试出的成绩 对 windows 不公平。 sony fan 的意思。



欢迎光临 POPPUR爱换 (https://we.poppur.com/) Powered by Discuz! X3.4