Linked by Thom Holwerda on Thu 21st Feb 2013 18:18 UTC, submitted by twitterfire
Games Late last night, Sony unveiled the PlayStation 4 - sort of. It's got a custom 8-core AMD x86-64 processor, 8GB of GDDR5 RAM, and a custom Radeon-based graphics chip. It's also got additional chips to offload specific tasks like video (de)compression (livestreaming is built-in!), and there's a large focus on streaming games, but most of it is "an ultimate goal" instead of a definitive feature. It won't play PS3 discs (but will eventually stream many PS3 games), and, while there's some weaselwording involved, second hand games are safe. The biggest surprise? The console itself wasn't shown because it's not done yet. No joke. No price, no release date (other than somewhere before the holidays).
Thread beginning with comment 553528
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Not impressive
by RareBreed on Sun 24th Feb 2013 01:54 UTC in reply to "RE[2]: Not impressive"
Member since:

Processing power, ram and latency isn't a problem. Disk I/O is.

Ram and latency are most definitely an issue. Just as Disk I/O is orders of magnitude slower than RAM access, RAM access is orders of magnitude slower than Cache access.

No matter how fast your storage (disk) subsystem can spit out data, it's not going to be anywhere close to as fast as getting it from memory. And ditto, getting data or instructions from cache is far superior to making the processor use it's memory controller to look up an address from some page table and do the virtual to physical lookup.

If you have enough RAM to fit all the game data into sytem RAM, so much the better. Unfortunately, SRAM is way too expensive, and even now, 128K Harvard architecture split data/instruction caches is considered pretty good. Getting access to L1 cache can take just a few clock cycles. Getting memory from system RAM takes a few hundred clock cycles generally speaking. But whereas system RAM access is measured in micro or even nano seconds, disk IO is stilled measured in milliseconds. In other words, disk access is thousands of times slower than RAM access. If you're page faulting and have to swap to disk, you're in BIG trouble in a game. The idea is you pull data from storage into RAM. RAM times are so important, that many developers don't even use malloc or new, and they pre-allocate their own heaps (memory allocation is expensive and can put the processor to sleep, not to mention the problem with memory fragmentation).

In regards to processing power, the name of the game is concurrency. Many systems are now merging the concept of CPU and GPUs so that the massively parallel processing of GPU's can work on all the highly vectorized game data (usually graphics, but physics too). But many other components will still rely on the main CPU (artificial intelligence for example). Splitting data across multiple threads of execution is very challenging.

Is a game more GPU or CPU bound? Depends on the game I suppose (I'm not a game developer, I'm a storage controller device driver developer). But again, processing and especially optimizing parallelization and concurrency will provide FAR greater beneft than disk IO.

Reply Parent Score: 3