@ Deneidez
Some of the dev quotes from e-mpire forums:
"asset-wise 360 was around first, so we made stuff keeping the 360 in mind first."
"Well, that all depends on your definition. Writing code optimized for the PS3 and using threading policies that are suited the SPUs is a given, because not doing so would not be acceptable at all. All our multithreading is done on PS3 first without exception, and other platforms emulate SPURS."
"Secondly, the matters of multithreading policies, the whole job queue architecture, encapsulation of jobs and their corresponding data packets, etc. that work on the PS3 are indeed more than applicable of the 360/PC. And as I've mentioned before, they work better than anything and everything that Microsoft recommends (so far without exception for us). The problems lie in the fact that that work is an absolute necessity on the PS3, whereas they're not entirely necessary on any other platform."
The eDRAM approach is much cheaper than having seperate RAM with seperate buses. It's not an approach used for PCs because eDRAM becomes expensive if you want to have enough of it (which is not the case for the 360, but would be a requirement for a gaming PC, it's an approach which mostly makes sense on last gen low res consoles).
The PS3's low latency XDR ram approach is also expensive compared to PC solutions, but more important than costs it's because the Cell really requires (mostly, it can also be used by the RSX) dedicated low latency RAM to get the most out of this architecture (like being used as stream processors).
