Slashdot Mirror
Playstation 3 Gathering Components
briancnorton writes "Cnet has a story about how Sony has licensed some Rambus connection technology for the playstation 3. One technology is for chip-to-chip communications and the other for chip-to-RAM at over 100 Gbps. These are all parts of the 'Cell' processor system that is supposed to do over '1 trillion mathematical calculations per second.'"
Can be found here.
--
Error 500: Internal sig error
You've got it backwards actually. Servers tend to have lots of random access, so they need low latency. Modern games tend to stream a lot of data, so bandwidth becomes more important. There is a reason why the P4/RDRAM combo excelled at Quake 3 Arena; oodles of bandwidth.
Streaming applications: bandwidth is the most important
Apps with lots of random memory access: latency is far more important.
The PS2 still is hard to program for. The difference is that now there are some libraries that can be used to simplify things. In the beginning everyone was forced to do things in pure assembly (OK, ALMOST pure assembly). But now the companies that have been working on PS2 games for years have developed libraries and engines that are already optimized. Haven't you noticed that most games that come out of the same development studio have the same look and feel? Of course each game is a bit more refined, but overall stageringly similar.
It seems to be a common misconception that the PS2 has multiple CPUs. It doesn't. What it does have is a single CPU that is split up into several independantly operating units. The dual-CPU idea developed from the fact that the Emotion Engine has two vector processing units that operate almost exactly the same. These two units make up the bulk of the mathematical processing in the PS2, and must be coded separately.
All of the code I've written for them has been in assembly and the process is GRUELING. Each unit actually performs two operations at once, a lower and upper instruction. Since the ultimate goal is optimization you end up writting all your assembly and then rearranging everything so that the combination of upper and lower instructions don't step on top of each other and everything runs without any wasted clock cycles. I have heard of a few tools that have been developed to compile C into optimized VPU code, but I haven't used any and I doubt they work very well. A good camera manipulation program will only take maybe a hundred lines of assembly if it's optimized correctly, but I bet these programs spit out many many more.
(Wow, I really steered off the original topic didn't I?)