On Tue, Feb 08, 2005 at 08:26:02AM -0600, Stephen Reed wrote: > The published hardware description of the Cell SPUs: 128 bit vector > engines, 128 registers each, matches the published Freescale AltiVec > processor architecture. I've looked over the programmer's documentation
It's eight 4x32 bit engines, with dedicated on-die memory and explicit-addressing shared memory, apart from the Power5-ish main CPU. I don't see any documentation of inter-Cell clustering yet. It'd be trivial to put SCI on-die. I'd be very surprised if they did, though. > for that processor and believe that vector processing is of limited > usefulness for the typical Cyc knowledge base instruction trace. As you No disagreement there. > know, vector computations are well suited for fine-grained parallelism in > which a single operation is applied simultaneously to multiple operands. Notice that you've got 8 asynchronous cores of these. It's a SIMD and MIMD system both. Granted it's numerics, but then most problems are that (AI especially, or at least AI can be written that way). > In Cyc, there are more opportunities for large-grained > inference parallelism as opposed to fine-grained parallelism. > > As the Cell programming model unfolds, it will be interesting to see just > how much entertainment (game) AI programming will use the Cell SPUs as > compared to using the Cell's conventional Power-derived GPU. I predict Current game AI is that by label only. The SPUs would be great for nonalgorithmic/neuronal type of creature control -- but given that they will be absorbed by increased game world complexity (physics engines) they will be unavailable for that in typical console settings. > that no game AI algorithm will use the SPUs. This could be verified by > examining the marketing claims of the game development code libraries that > are sure to appear in the next couple of years. Yes, I expect very detailed game physics, not much beyond that. > Generally, I find that the Cell architecture is further evidence that > Moore's Law performance expectations will hold for several more > lithography nodes (process technology generations). In particular, the > use of chip area for multiple cores as opposed to simply more cache > memory is a step in the right direction. A spreadsheet I maintain Absolutely -- and they did the right thing by ditching the core for the SPUs. > predicts that the x86 architecture will be 256 cores per chip at the 3.76 > nanometer node, in the year 2022, which is nine lithography generations I don't expect conventional lithography electronics to go beyond 2015. Also, x86 architecture and power dissipation densities break down before. They have to go full scale nanoelectronics by 2022, which will be most likely bucky electronics, spintronics and MRAM. > from now. My assumption is that the number of cores will double with > each lithography generation, and that Intel will continue to migrate to a > new generation every two years. It would suit Cyc-style AI processing Intel is having big problems with their x86 approach. Multicores will only bring them that far, so they have to prepare a successor technology. > best, if multi-core CPUs evolved in the direction of high performance > MIMD (multiple instruction, multiple data) integer processing, as > compared to the Cell SIMD (single instruction, multiple data) floating > point processing. What I don't like about Cell is lack of 8 bit and 16 bit integer data types in SPU SIMD. I'm also missing discussion on whether the SPUs are connected by a crossbar (there might be no need for it, if the internal bus is really fast and wide), and which signalling interconnect Cell clusters will use. I'm really hoping they will ship a flavor with a torus network a la Blue Gene (will there be Cell Blue Gene?) -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
pgpXs5ES0Pnd9.pgp
Description: PGP signature
