Sony Losing Almost $250 Per Console


Okay well my friend installed Fedora 5 on her PS3, the day it was released, and she didn't pay anything for it so that proves both Epicenter and darkman wrong. And I never said that it came on board, actually in my post I said you had to install it, but so what? You have to install Linux on a computer you'd build yourself too, oh no.

Just because someone is offering a PS3 Linux distribution for $50 doesn't mean there aren't others and it doesn't mean they all cost money. You can buy distributions for PC too, doesn't mean you can't get them for free. A Wikipedia article isn't necessarily an exhaustive source of information, it was just listing an example.

A $400 computer might be suitable as a Linux box but a PS3 will ALSO be a top of the line gaming platform if you don't already like the games. I'm saying there's incentive to get it now because it's not JUST a next gen gaming machine.

And obviously if it can run Linux out of the box it is not following the same unsigned code protection scheme PSP is...

And what is this about having to use an expensive HDTV? You can use an HDMI->DVI cable and hook up an ordinary LCD monitor. You can use it EXACTLY like you would any other computer, why is this so hard to understand?

First my response,

:)

Now after that, maybe I should tackle this from another angle. Let me understand this.
You paid $600.00 for a PS3 and Loaded up Fedora Core 5. (The wiki did show a link with Fedora Core 6 running on PS3.) It has a Power PC 3.2 Ghz CPU (It has Cell processing capabilities, but Linux does not have the drivers to support that in the PS3. I am sure someone will correct me if I am wrong. So basically you have a 3.2 Ghz CPU.) You do have Nvidia G70 video, and Linux does sort-of support Nvidia. I really don't think there is anything in Linux that uses Nividia to its fullest capabilities. You also have 256 MiB of Rambus XDR DRAM (can you add more ram? I don't know.) and a , I'm assuming, 60 GB Hard Drive. So basically You can do no more with your PS3 running Linux than I can with a home built box under $400.00 running the same Linux Distro. Maybe the ability to load Linux out of the box had something to do with them planning at some point to include a Linux Distro on the hard drive.

So the only real advantage that I see is You bought a PS3 and you can run Linux on it and use it as a computer and still have your PS3 games. ;) If that is what you enjoy go for it.
 
Last edited by a moderator:
Just in case you're actually referring to me directly, I didn't buy a PS3.

Anyway, right now the $400 PC might be competitive, but when the Cells are more accessible and there are better video drivers it'll be a much different story.

Rough estimate of what a $400 PC gets you:

CPU - low end single core Athlon64, $100
Motherboard - $60
512MB of DDR RAM - $60
Case + PSU - $35
GF6200 level video card - $35
DVD-RW - $30
100GB HDD - $50

Fill in the rest with whatever mild improvements + S&H (since you probably won't buy it locally)

If you want more HDD space and the ability to burn DVDs the cheap PC is better, or if you need the extra RAM. The PS3 still has vastly more overall computational power, and it won't take a lot of support to get much more out of the 3D capabilities and CPU than this PC can offer.

But yes, it's something offered in addition to being able to play games, I wouldn't expect anyone to buy it solely for usage without commercial games (unlike PSP which actually does happen)
 
Just in case you're actually referring to me directly, I didn't buy a PS3.

Anyway, right now the $400 PC might be competitive, but when the Cells are more accessible and there are better video drivers it'll be a much different story.

Rough estimate of what a $400 PC gets you:

CPU - low end single core Athlon64, $100
Motherboard - $60
512MB of DDR RAM - $60
Case + PSU - $35
GF6200 level video card - $35
DVD-RW - $30
100GB HDD - $50

Fill in the rest with whatever mild improvements + S&H (since you probably won't buy it locally)

If you want more HDD space and the ability to burn DVDs the cheap PC is better, or if you need the extra RAM. The PS3 still has vastly more overall computational power, and it won't take a lot of support to get much more out of the 3D capabilities and CPU than this PC can offer.

$400 doesn't make sense; you should really be comparing it to a $600 PC. In that price range you can afford a Dual-Core Athlon X2 3800+ (which is much more powerful than the Cell processor for most tasks, since tasks that processor is good at are very specialized. You won't be able to see its true performance in Linux except in some custom programs that run code directly on the individual vector processing units, which will be nothing right now, maybe a few things down the road, but the vast majority of software would have to be entirely rewritten from the ground up to use them properly. So, you are looking at just the main PowerPC core, which is not as fast as a 3.2 GHz Pentium 4 or its Athlon 64 equivalent-- estimates by John Carmack of iD Software (author of the Wolf3D/Doom/Quake engines, widely regarded as a god in programmer form, able to squeeze marvels from even the lowest-end hardware) rated the CPU are operating around the speed of a 1.4 GHz Pentium 4 in most situations. Linux will see just that ONE CPU for the same reason it only sees the 920T in the GP2X, essentially. The other procesors will not operate in SMP.

Of course, with very specialized code designed for vector processors, many PS3s in parallel, running Linux, as a supercomputing cluster make sense. Tasks like compression, code-breaking, scientific apps will work very well on such a processor. While I think a platform that doesn't provide GPUs, VRAM, HDDs and other components useless for supercomputing and just implements many, many cell processors together with minimal overhead is more ideal, it would work just fine this way. For desktop computing, however, the Cell processor's advantages are largely absent leaving one rather anemic core that was really meant to call the shots on the vector processors, not perform a huge processing load on its own-- and is therefore rather inefficient and outmoded compared to modern desktop CPUs.

Video, the closest thing is probably a GeForce 7xxx series card like the 7800GT. (FYI, using this GPU with Linux, with some fiddling with the nVidia drivers, should be achievable without too much difficulty. Accessing the graphics hardware over whatever strange bus the PS3 uses rather than PCI-Express is the greater challenge.) RAM; about 512MB of DDR400 or DDR2-533 would run you only $50-ish, or less for a more generic brand like Patriot rather than Corsair/Kingston/Crucial. A motherboard will run you less than $60, a cheaper model under $50. A 160GB HDD can be had for ~$50. A double-layer NEC DVD+/-RW drive will run you only $30, then add a case and a very good Antec or Enermax PSU for ~$50. You'll come in right around the $600 mark. That nets you a far faster CPU, a more versatile overall system connectivity-wise, more RAM, more HDD space, a full suite of optical media capabilities (no Blu-Ray of course, but it's not really useful at the moment, and won't be for quite some time).
 
Last edited by a moderator:
Sony is in control. (I am guessing at this.) Sony is actually running a software program that detects when you are installing Linux. You are then directed to a Virtual Computer program. You install Linux into this program and run Linux as a Program. You do not have full access to the Hardware. You are allowed to install Linux into a place that they have fixed on the hard drive. Their protection is still in place. You do not have access to their filmware. You are probably given a choice when you turn the machine on, you can boot up the PS3 filmware or Fedora or you boot up into the filmware and it asks you if you want to run Linux? If this is the case, you may not be able to have any drivers to use their hardware in Linux. They are in control. This is not the same as someone hacking into the PSP and using Sony's own filmware to run programs that they have written. In order to take advantage of the PS3, someone would have to hack into Sony's filmware or OS that they have running. You are stuck at this point with a virtual computer that they have given you.

Knowing Sony and their zeal to protect their stuff and control it, I don't think that I am far off in this theory. In that respect you may not be running Linux on a $600.00 PC.
 
Epicenter; Please link me to where John Carmack says that the PS3's CPU w/o the SPEs is like a 1.4GHz P4, because I'm having a hard time believing that.
 
This information was released by Anandtech in a report much earlier this year when the PS3 hardware was first revealed. If you want to look through the archives on http://www.anandtech.com you'll find it there. He said the same about the XBox 360's CPU, actually. Which under normal game conditions, is true. It's exceedingly difficult to make use of the multiple processing cores in a game engine as it is. 'Cell's layout makes it more difficult than the 360's 3 SMP'd cores, though.
 
I assume you mean this article?

http://www.anandtech.com/showdoc.aspx?i=2379&p=1

Because if you do, nowhere does it quote Carmack. It does say that the PPE core by itself appears weaker than a top of the line Intel or AMD CPU (as of the writing of the article, March 2005), but nowhere does it put it on the same level as a 1.4GHz Pentium 4, a 6 year old CPU that was pretty terrible even in its own time.

For a 3.2GHz PPC based 64bit CPU w/2 way SMT (similar to hyperthreading) and AltiVec to be equivilent to a 1.4GHz P4, well, they'd have to be doing a lot worse than just having in order execution.

And I don't know why people are downplaying the SMEs so much, that is to say, I don't see any good reason why they can't be used as general purpose units. Sure, they wouldn't do that well, compared to how they'd do in actual vector computations, but they're still pretty general in their capabilities and I could see actual OS scheduling making use of them.

In the XBox 360's case it's actually a triple core processor that's probably relatively competitive against current high end dual core CPUs - if you're going to call it specialized then you'd may as well call all multi-core CPUs specialized.
 
This is not the article in question. It regarded architecture of the PS3 and the XB360, and did quote Carmack. All that'd be necessary for the performance to be that low is for the design to be inefficient and provide low IPC. Compare Intel's Northwood architecture to their Conroe architecture, or AMD's K8 architecture. Northwood processors have longer pipelines and therefore far more transistors, run hotter, use more power, and have much lower overall efficiency, handling far fewer instructions per cycle than the aforementioned two architectures. It'd really just be a dead-end design that cannot be scaled much further for a logically marketable series of processor, and due to that lack of demand would be cheap and easy to relegate to a 'controlling' processor in the 'Cell', or as a cheap core to put 3 of in the 'Xenon'. Most games for consoles are not physics-heavy and with no major OS demands to speak of compared to a PC, the role of the CPU is minimized compared to the bottlenecks of the GPU, main RAM speed, and bandwidth between the GPU and VRAM-- so it's appealing to Microsoft and Sony to play the "It has an army of processors!" card for marketing's sake, even if it won't help performance and one faster processor would've done the job better.

Sega played this card back with the Sega Saturn. One of their commercials showed a PSX being thrown out a window, saying it couldn't handle NiGHTS into Dreams because it had only one processor, while in reality, even if the twin SH-2 processors in the Saturn were a good marketing gimmick, flaws in their implementation made using both processors simultaneously nearly impossible in most situations, such that one faster processor would have yielded better performance, more ease of development, less engineering time and lower production cost. The same logic applies to Sony and Microsoft.

Sony took this route because, like the PS2, they needed a new marketing gimmick. The PS2 had the 'Emotion Engine', which was hyped to be a marvel of modern technology, so powerful it was a weapon of mass destruction and lets you connect to the Matrix. :p Turns out it was just a high-clocked MIPS core, a beefed up architecture that's been around for decades now. Whoops. So, this time around, we have the "Cell" which is "supercomputer" technology (it's too bad games don't demand the same sort of processing supercomputing tasks do) and "is capable of creating artificial life". Sure, it cost Sony an arm and a leg to get the processor designed, the yields are awful and they cost a fortune compared to one simple, fast processor. But now Sony has a new marketing gimmick and all is right with the world.

Microsoft couldn't let on that they just had ONE processor, after all, next thing you know XBox 360s would be falling out of windows on international TV! They'd be a laughing stock! So, let's not include one FAST processor, let's have 3 slow ones that produce an obscene amount of heat and draw so much power that the machine needs a brick that is nearly the size of the Wii on its own and a fan so noisy it can drown out some TVs! That'll show those Sony bastards, right? :rolleyes:
 
This is not the article in question. It regarded architecture of the PS3 and the XB360, and did quote Carmack. All that'd be necessary for the performance to be that low is for the design to be inefficient and provide low IPC. Compare Intel's Northwood architecture to their Conroe architecture, or AMD's K8 architecture. Northwood processors have longer pipelines and therefore far more transistors, run hotter, use more power, and have much lower overall efficiency, handling far fewer instructions per cycle than the aforementioned two architectures.

Yes, because transistor count, heat emission, and power usage contribute a whole lot to average instructions per cycle. Northwood was relatively competitive with its contemporary AthlonXPs because it made up for IPC with clockspeed, it just meant that they weren't clock for clock comparable.

It'd really just be a dead-end design that cannot be scaled much further for a logically marketable series of processor, and due to that lack of demand would be cheap and easy to relegate to a 'controlling' processor in the 'Cell', or as a cheap core to put 3 of in the 'Xenon'.

I'm not saying that the Cell's PPE or each of Xenon's cores are competitive with modern K8 and Core 2 cores, I AM saying that they're far superior to a P4 1.4GHz, and I have yet to see this magical quote from you (searched another AnandTech article, nothing).

Most games for consoles are not physics-heavy

I think the idea is to make them more so now, of course a bunch of heavy vertex processors helps here far more than a few powerful general purpose cores, why do you thing "physics cards" received the attention they did?

and with no major OS demands to speak of compared to a PC

On a PC the OS itself has almost no overhead (not counting things like rendering fancy GUIs which wouldn't be done when using apps fullscreen anyway.. but that's not an OS issue)

, the role of the CPU is minimized compared to the bottlenecks of the GPU, main RAM speed, and bandwidth between the GPU and VRAM-- so it's appealing to Microsoft and Sony to play the "It has an army of processors!" card for marketing's sake, even if it won't help performance and one faster processor would've done the job better.

Yes, that's why PC's have been moving towards multicore with 4, 8, and higher cores coming up. Obviously the push is there for games too, because single core in general has met a dead end. And for games having several vector units is by far the most powerful feasible solution.

Sega played this card back with the Sega Saturn. One of their commercials showed a PSX being thrown out a window, saying it couldn't handle NiGHTS into Dreams because it had only one processor, while in reality, even if the twin SH-2 processors in the Saturn were a good marketing gimmick, flaws in their implementation made using both processors simultaneously nearly impossible in most situations

Yeah, that's pretty much bogus, it was just a matter of developers not actually utilizing it because it was harder. You sound like you're confusing it with another platform.

, such that one faster processor would have yielded better performance

I don't think so, unless we're talking dramatically faster, which wasn't really an option when they began developing these things.

, more ease of development, less engineering time and lower production cost. The same logic applies to Sony and Microsoft.

Right, the hardware behind PS3 and XBox 360 is actually inferior and they're spending tons of extra money on marketing hype. :rolleyes:

Sony took this route because, like the PS2, they needed a new marketing gimmick. The PS2 had the 'Emotion Engine', which was hyped to be a marvel of modern technology, so powerful it was a weapon of mass destruction and lets you connect to the Matrix. :p Turns out it was just a high-clocked MIPS core, a beefed up architecture that's been around for decades now.

And two rather powerful vector units.. again, it was a matter of getting people to use them, not to say PS2 didn't have other problems.

Whoops. So, this time around, we have the "Cell" which is "supercomputer" technology (it's too bad games don't demand the same sort of processing supercomputing tasks do)

Actually, almost everything in scientific computing revolves around vector math (matrix/vector multiplications) and guess what, so does almost everything in modern gaming, including any manner of graphics and physics. Just what having several highly parallelizeable vector units is good for!



and "is capable of creating artificial life". Sure, it cost Sony an arm and a leg to get the processor designed, the yields are awful and they cost a fortune compared to one simple, fast processor. But now Sony has a new marketing gimmick and all is right with the world.

Whatever you say man. I won't argue that it costs more and I won't argue that it's harder to use but I'll be damned if you're going to convince me that it doesn't pack more theoretical power.

Microsoft couldn't let on that they just had ONE processor, after all, next thing you know XBox 360s would be falling out of windows on international TV! They'd be a laughing stock! So, let's not include one FAST processor, let's have 3 slow ones that produce an obscene amount of heat and draw so much power that the machine needs a brick that is nearly the size of the Wii on its own and a fan so noisy it can drown out some TVs! That'll show those Sony bastards, right? :rolleyes:

Sorry, but one "fast" processor is never going to even come close to the aggregate performance of the 3 cores combined in the XBox 360, IF utilized well.

You can stammer all you want about this but multicore is where the industry is and where it will continue to be. Wake up, this isn't the future, it's where we're at RIGHT NOW.

Yes, Wii isn't going that way, but that's because Nintendo wants to focus on price and other innovations and has stopped trying to be overly competitive in terms of hardware. Not because they've realized their slow single core CPU is actually faster than everyone else's.
 
Last edited by a moderator:
The game industry has gotten pretty much nowhere so far with parallelizing game engines, and most average users can't see any real benefit from multi-core processors yet, because they don't multitask as heavily as someone like me or you likely does-- compounded with that most software is single-threaded. The benefits from say, a 4- or 8- core processor won't truly be seen for most users until CPU architecture allows for the splitting of one thread into many, for execution on general-purpose or specialized cores. The idea's been tossed around before, and it is rumored AMD and Intel are both working on the concept. Once this happens, a processor's speed can scale in linear fashion with the number of cores included, without concern for software-- as long as heat and power issues are kept in check. This hasn't happened yet, and the XB360 and PS3 also lack the ability to derive instructions for multiple cores from one thread. Most engines do not use anything but one of the XB360's cores right now, and it will stay that way for quite some time. Many developers will never bother trying to use all 3, but let's face it, some code just does not parallelize effectively at the programmer's or compiler level-- it has to be done at the hardware level or not at all.

Due to the present situation with multicore processors, one faster CPU core would probably have been more cost-effective, while providing higher performance per programmer hour invested. I would consider this a more logical course of action, at least in a game console. If we were talking about marketing the PS3 as a node for a supercomputing cluster, its design would make sense, but as a game console, it really doesn't.

Yes, the PS3's "Cell Processor" has considerable potential. The problem is that while this power, if properly tapped, will result in extremely high computational ability, in a game scenario it is not realistic. I am well aware vector/floating point math comprises the majority of what a game engine does (I've worked with 3D engines firsthand; for example, Quake has no support for any integer data types, period. It's almost 100% FP code), but this is not the reason the Cell processor is poorly suited to a game. A vector processor's structure like the Cell's is as such. A "master" processor passes instructions to multiple RAM-limited vector processor cores-- generally to perform one operation over a MASSIVE data set. This allows very fast execution of repeat operations, such as complex math, compression, encryption, code-breaking, etc. as I have said. This is because the processors will not need to recieve new instructions frequently, will not access the Main RAM frequently, and can just churn out results of the same variety over and over with little to no intervention by the "Master" processor.

In a game situation, the same task is not being performed again and again. Every bit of game logic executed changes the situation to be processed and the math that must be done on the next frame. Every processor's results must be passed back to the Master and will fit into a larger, constantly-changing puzzle. This means the Master core must be constantly recieving interrupts and slowing its own work to listen to the vector units and pass them new instructions. Due to the way the vector units are tied to their own memory, they cannot operate independently of the Master core effectively. Since the situation they deal with is changing so constantly, they cannot operate even approaching peak efficiency for crunching real game logic. This will likely make them ineffective for real-time physics processing. A physics processor in present iteration isn't a vector processor, it's one very fast Vector FPU with a wide, fast path to memory, and that's it. Just like a GPU-- which is why nVidia and ATi are both working on implementing use of a GPU as a physics processor, or a second GPU core on the same die as one.

I have established you will not achieve peak efficiency or close to it in a real game scenario, but I must address your statement regarding time invested vs. results obtained-- yes, a skilled programmer can find a way to make the most of this situation, while a less skilled or lazy programmer will do a miserable job or skip the vector units altogether and code just for the Master core for equally abysmal performance but less hassle. The problem is, game development is usually rushed these days, with problems fixed in patches after the game is forced out the door in a frenzy. By the time a game is developed that is a veritable marvel of programming prowess, three games could have been built in the same time with less perfectionistic and effective methods. Companies care less about what is more ideal and beautiful code and perfect use of the hardware, than they do about their bottom line. Such code is also highly specific to the PS3 architecture and will not port cleanly to the XBox 360 or Wii. Most studios would much rather keep easily-portable single-threaded code that will run 'copy-and-pasted' into a port that can be sold for the Wii, XB360 *and* PS3 than worry about optimizing for one or the other. That's just a revenue vs. time equation right there, and the idealistic programmer generally doesn't win in such situations.

Regarding Northwood, I never stated heat and power consumption impacted IPC. I stated a longer pipeline necessitated more transistors, which produced more heat and used more power. I used Northwood as an example because it was not clock-for-clock competitive with Athlon XPs and 64s, or 'Core'-series architectures from Intel, for a reason. It is often regarded that a 3.2 GHz PowerPC chip used in the PS3 or XB360 is necessarily competitive with a 3.2 GHz Pentium-D or other modern dual-core processor, while in actuality, the performance may be dramatically lower-- such that a 2.8 GHz Northwood P4 did not stand up to a 2.8 GHz Athlon 64. For the two to have relatively equal playing ground, you'd be looking at more of a 4.1 GHz+ P4 to match the A64 at 2.8 GHz. Another example might be the Z80 vs. the 6502 to look at a more classical example-- the Game Boy had a Zilog Z80-based processor at nearly 4 MHz that performed on par with the NES' 1.79 MHz 6502 and sometimes ran slower, because the Z80 took nearly twice as many instructions to get the game job done as on the 6502's instruction set! It is not unrealistic to think, that with a 2:1 performance gulf, such could exist in the realm where the compared clockrates are not ~2 and ~4 Mhz, they are ~1.5 GHz and ~3 GHz.

As for your statements regarding the Saturn, the reason for its failure was not laziness on the part of programmers. There were true design faults in the implementation of the dual-processor configuration. Both CPUs could not utilize RAM at once, and had no cache whatsoever. As a result, one processor was generally stalled while the other was working unless RAM could be shuffled between the two chips when neither needed to access it-- which was relatively infrequent. The amount of time required to delegate tasks between the two correctly, like the PS3 situation, didn't equate well to a design timeframe and the bottom line. It was easier to just code for one CPU and ignore the other, or cancel the project altogether and jump ship for the PSX. Other problems with the Saturn involved the fact that it contained not just the twin SH-2 processors, but also a 68000 processor for audio, a complex audio subsystem, and an EXTREMELY complex video subsystem involving two VDPs, and a bizarre quad-based rendering system (not triangle based) which was designed for display of 3D-accelerated display of sprites 'stretched and scaled' by manipulating polygons instead of 2D tile data, which was then applied to more 3D games than 2D, resulting in unneeded complexity in model design and manipulation (nearly all 3D tools were, and still are, based on Triangles, not Quads.) Sega really did have a lot more going for it with the dual-processor marketing than the architecture of the machine in this case. I believe that philosophy made a comeback.
 
I can't see EA investing time in optimising their code for specific multi-core systems :) Actually, maybe we need this to be a close battle between the two systems in order for Microsoft/Sony to push their teams to get the most out of their machines. Although, I would rather they were putting their resources specifically into gameplay.. like Nintendo.
 
Witha hardware like this, i don't want to be expected to buy a new console for at least 7-9 years. There is no reason to update before then.
There's not even a reason to upgrade *now*, but meh. The next gen will happen in roughly (less then) five years from now, mark my words.

Their greed knows no limits.

- Alex
 
Last edited by a moderator:
The game industry has gotten pretty much nowhere so far with parallelizing game engines, and most average users can't see any real benefit from multi-core processors yet, because they don't multitask as heavily as someone like me or you likely does-- compounded with that most software is single-threaded. The benefits from say, a 4- or 8- core processor won't truly be seen for most users until CPU architecture allows for the splitting of one thread into many, for execution on general-purpose or specialized cores.

That's a problem of programming paradigm. People don't like dealing with multi-threading because it involves worrying about synchronization, but that doesn't mean it can't be done in a lot of places where it isn't.

The idea's been tossed around before, and it is rumored AMD and Intel are both working on the concept. Once this happens, a processor's speed can scale in linear fashion with the number of cores included, without concern for software-- as long as heat and power issues are kept in check.

I honestly don't really see how a single thread could literally be split into many in any conceivable fashion, but if it is possible then that even further solidifies that lack of multi-threading is a programmer problem.

This hasn't happened yet, and the XB360 and PS3 also lack the ability to derive instructions for multiple cores from one thread. Most engines do not use anything but one of the XB360's cores right now, and it will stay that way for quite some time.

Again, that's a programmer problem, not a hardware one. Clearly the big companies are trying to force a paradigm shift because multi-core is the only real way of the future at the moment, for classical computing anyway.

Many developers will never bother trying to use all 3, but let's face it, some code just does not parallelize effectively at the programmer's or compiler level-- it has to be done at the hardware level or not at all.

Thread level parallelization is a lot different from the kind of vector level parallelization you're talking about, and I really don't think that hardware can split things into threads in a way that a programmer can't. Actually, the idea sounds ridiculous since programmers know much more about the typical data flow of a program than hardware can tell at runtime.

Due to the present situation with multicore processors, one faster CPU core would probably have been more cost-effective, while providing higher performance per programmer hour invested.

Obviously this isn't about "performance per programmer hour", like with PS2 both Microsoft and Sony are making programmers work significantly harder so they can achieve better results in the end.

But given that a vast majority of a game's budget is spent on graphics anyway is it such a huge burden to shift some of that back to programming?

I would consider this a more logical course of action, at least in a game console. If we were talking about marketing the PS3 as a node for a supercomputing cluster, its design would make sense, but as a game console, it really doesn't.

And yet if you compare what farms with high computing capabilities often actually do, such as render farms, with what GAMES do...

Yes, the PS3's "Cell Processor" has considerable potential. The problem is that while this power, if properly tapped, will result in extremely high computational ability, in a game scenario it is not realistic. I am well aware vector/floating point math comprises the majority of what a game engine does (I've worked with 3D engines firsthand; for example, Quake has no support for any integer data types, period. It's almost 100% FP code),

Who ever said anything about floating point vs. integer? Floating point usage is a downright given.


but this is not the reason the Cell processor is poorly suited to a game. A vector processor's structure like the Cell's is as such. A "master" processor passes instructions to multiple RAM-limited vector processor cores-- generally to perform one operation over a MASSIVE data set. This allows very fast execution of repeat operations, such as complex math, compression, encryption, code-breaking, etc. as I have said. This is because the processors will not need to recieve new instructions frequently, will not access the Main RAM frequently, and can just churn out results of the same variety over and over with little to no intervention by the "Master" processor.

Okay, for one thing the Cell processor has internally extremely high peak bandwidth, much higher than any RAM subsystems. For another thing, the SPEs are general purpose processors that don't need to be given static control flow commands from the "master."

In a game situation, the same task is not being performed again and again.

Certainly it is. Within a single frame there are many of the same operations being performed over a huge set of data. Transformation and lighting obviously, but even moving away from graphics rendering, physics and collision...

Every bit of game logic executed changes the situation to be processed and the math that must be done on the next frame.

And yet the working data set within a single frame is huge.

Every processor's results must be passed back to the Master and will fit into a larger, constantly-changing puzzle. This means the Master core must be constantly recieving interrupts and slowing its own work to listen to the vector units and pass them new instructions.

Like I said, the bandwidth is massive, and obviously they can communicate via memory and not interrupts.

Due to the way the vector units are tied to their own memory, they cannot operate independently of the Master core effectively. Since the situation they deal with is changing so constantly, they cannot operate even approaching peak efficiency for crunching real game logic. This will likely make them ineffective for real-time physics processing. A physics processor in present iteration isn't a vector processor, it's one very fast Vector FPU with a wide, fast path to memory, and that's it. Just like a GPU-- which is why nVidia and ATi are both working on implementing use of a GPU as a physics processor, or a second GPU core on the same die as one.

And yet the physics cards available now are very similar to what we have going on with PS3 - they're graphics card shader units (parallel vector units, just like the SPEs) that pump data back and fourth to a main CPU. The difference is that such physics cards have to go over much slower PCI-E bus, which is quite a bit different than the scenario you described, where Cell has the obvious bandwidth advantage.

I have established you will not achieve peak efficiency or close to it in a real game scenario, but I must address your statement regarding time invested vs. results obtained-- yes, a skilled programmer can find a way to make the most of this situation, while a less skilled or lazy programmer will do a miserable job or skip the vector units altogether and code just for the Master core for equally abysmal performance but less hassle. The problem is, game development is usually rushed these days, with problems fixed in patches after the game is forced out the door in a frenzy. By the time a game is developed that is a veritable marvel of programming prowess, three games could have been built in the same time with less perfectionistic and effective methods. Companies care less about what is more ideal and beautiful code and perfect use of the hardware, than they do about their bottom line.

Their bottom line is all about remaining competitive and getting the most out of hardware is the only way to do this. When companies like Sony and Microsoft drive more difficult to use (but more powerful) platforms the end developers don't really have a choice but to utilize it well, if they want to be competitive.

Such code is also highly specific to the PS3 architecture and will not port cleanly to the XBox 360 or Wii. Most studios would much rather keep easily-portable single-threaded code that will run 'copy-and-pasted' into a port that can be sold for the Wii, XB360 *and* PS3 than worry about optimizing for one or the other.

They might want that, but they won't get that if they want their games to be competitive, like I siad.

That's just a revenue vs. time equation right there, and the idealistic programmer generally doesn't win in such situations.

It doesn't really matter, why should I care about what game companies can do to make money more efficiently if it means churning out inferior games?

Regarding Northwood, I never stated heat and power consumption impacted IPC.

No, you just listed those things with it, even though they were 100% irrelevant.

I stated a longer pipeline necessitated more transistors, which produced more heat and used more power. I used Northwood as an example because it was not clock-for-clock competitive with Athlon XPs and 64s, or 'Core'-series architectures from Intel, for a reason. It is often regarded that a 3.2 GHz PowerPC chip used in the PS3 or XB360 is necessarily competitive with a 3.2 GHz Pentium-D or other modern dual-core processor, while in actuality, the performance may be dramatically lower-- such that a 2.8 GHz Northwood P4 did not stand up to a 2.8 GHz Athlon 64. For the two to have relatively equal playing ground, you'd be looking at more of a 4.1 GHz+ P4 to match the A64 at 2.8 GHz. Another example might be the Z80 vs. the 6502 to look at a more classical example-- the Game Boy had a Zilog Z80-based processor at nearly 4 MHz that performed on par with the NES' 1.79 MHz 6502 and sometimes ran slower, because the Z80 took nearly twice as many instructions to get the game job done as on the 6502's instruction set! It is not unrealistic to think, that with a 2:1 performance gulf, such could exist in the realm where the compared clockrates are not ~2 and ~4 Mhz, they are ~1.5 GHz and ~3 GHz.

I understand what you're saying, so does everyone. But just because it's possible for a 3.2GHz CPU to perform on the same level as another 1.4GHz CPU, in THIS case I really don't see that as likely. Not a 1.4GHz Willamette.

Oh, and things have changed a lot since the days of early CISC CPUs, in terms of how long it takes to do what.

As for your statements regarding the Saturn, the reason for its failure was not laziness on the part of programmers. There were true design faults in the implementation of the dual-processor configuration. Both CPUs could not utilize RAM at once, and had no cache whatsoever.

Okay, you're just flat out wrong there, both CPUs had 4kb of cache and could map RAM directly with it.

As a result, one processor was generally stalled while the other was working unless RAM could be shuffled between the two chips when neither needed to access it-- which was relatively infrequent. The amount of time required to delegate tasks between the two correctly, like the PS3 situation, didn't equate well to a design timeframe and the bottom line. It was easier to just code for one CPU and ignore the other, or cancel the project altogether and jump ship for the PSX.

Right, so now we're talking about what's easier, as if this is very different from "lazyness"

Other problems with the Saturn involved the fact that it contained not just the twin SH-2 processors, but also a 68000 processor for audio, a complex audio subsystem, and an EXTREMELY complex video subsystem involving two VDPs, and a bizarre quad-based rendering system (not triangle based) which was designed for display of 3D-accelerated display of sprites 'stretched and scaled' by manipulating polygons instead of 2D tile data, which was then applied to more 3D games than 2D, resulting in unneeded complexity in model design and manipulation (nearly all 3D tools were, and still are, based on Triangles, not Quads.) Sega really did have a lot more going for it with the dual-processor marketing than the architecture of the machine in this case. I believe that philosophy made a comeback.

Yes, Saturn was very DIFFICULT to develop for, and contained far more hardware than necessary. I'm not going to argue any of that, because it has nothing to do with what you originally said, which was that one faster CPU would have been more powerful than its two. And I said that unless that CPU was MUCH faster (which was not realistic at that time) that was not true.

EDIT: Is there some kind of forum bug with quotes? This is getting really annoying.
 
Last edited by a moderator:
Yes yes people, and today we can pack the N64 into a handheld the size of a paperback, and the genesis into a controller that plugs into your TV. Has anyone considered the fact that at the time, if they wanted to get the damn thing out and not spend 10 years researching it, THAT WAS THE BEST THEY COULD DO IN THE TIME ALLOTTED?
 
We both seem to be viewing the 'Cell' from very different viewpoints. Yours appear to be derived from your understandings of the development kit you have. Mine are based on the views of industry developers who've worked with the hardware. Which of us is correct in each aspect, it's really hard to be sure.

It doesn't really matter, why should I care about what game companies can do to make money more efficiently if it means churning out inferior games?
Because unfortunately this is the new methodology of the game industry, they will churn out whatever is the most efficient, not what is 'better'. They really don't care about our views on how a game program should be a finely tuned and optimized work of art, not a rush-job to 'just make it work', which is what most game engines are these days. Especially for consoles. More complex hardware is just going to make the rush worse and result in poorer utilization of the hardware in the name of the bottom line, portability to all 3 major consoles, and having to pay for fewer employee hours spent programming.

I honestly don't really see how a single thread could literally be split into many in any conceivable fashion, but if it is possible then that even further solidifies that lack of multi-threading is a programmer problem.
Current concepts of this technology include tasks such as breaking down a thread into dedicated cores for different operations (add/subtract, multiply/divide, specialized instruction sets like SSE1/2/3 etc. are prime examples). A programmer can't split up one thread to take full advantage of all the blocks of a modern processor as complex as now exist without the thread being divided up in some fashion. This is basically what's already going on with integer and floating point operations being handled by different portions of the processor-- it would just be expanded to deal with a larger scope of parallelization.

Other technologies to optimize the code at runtime long after the compiler and linker are through with it include Intel's "Macro-Ops fusion" technology in their new Conroe cores which combines multiple unnecessary opcodes into simpler, more efficient instructions to be run, thereby reducing the actual work to be done in realtime.

Certainly it is. Within a single frame there are many of the same operations being performed over a huge set of data. Transformation and lighting obviously, but even moving away from graphics rendering, physics and collision...
These operations involve changing the data set very frequently (e.g. collision, where many many objects must be checked, not just one). Same for physics. So it's not going to see the full advantage of vector processing ideology. As for transformation/lighting-- this should be getting done on the GPU, not the CPU. Very few engines use software lighting-- the only example I can think of that is modern is Doom 3's engine, which Carmack only implemented software light/shadow in because he did not like the way the graphics cards handled the tasks when he went through the API conventionally. Carmack's a bit old-fashioned in how he does some things, which is admirable in a lot of ways-- note his tendency to still use OpenGL rather than the mess that is Direct3D.

And yet if you compare what farms with high computing capabilities often actually do, such as render farms, with what GAMES do...
.. you'll find they're quite different tasks, especially since a renderfarm will produce graphics from a high-accuracy, low-speed graphics subsystem rather than a high-framerate, low-accuracy one like a modern GPU being used in a game situation will, or perform the rendering in software for even higher precision to dodge all the shortcuts inherent in modern APIs and GPU implementation.

As for the Saturn issue, we could argue this one all day, so I'm just going to drop it. Suffice to say you are correct on the cache issue, oversight on my part.

I'm going to cut this conversation short since we've already argued over this exact same issue before, and we never could come to a point of resolution (so I have no reason to believe we will this time, heh.)

My point is, there's no real room for programmers to work on such idealistic principles these days because of the nature of the industry, the importance of the bottom-line and the rush-job projects are completed in. Therefore more powerful, less complex and less difficult to utilize hardware is more well-suited to game consoles at this point in time. Even with consoles 20 years old, we see demos released by programmers with FAR more free time (no deadlines to meet) that work the hardware to its limits and do things no game ever did, and leave us wondering, 'Why didn't any of the commercial games use the hardware this extensively?' They were under the same pressures as today. But this was even the issue with a simple machine like the MegaDrive/Genesis made entirely with off-the-shelf parts, where the most proprietary component was the VDP, which was still based on a 1980s Texas Instruments design that was well-documented. It's even MORE true of a system like the PS3 or XB360 which is complex and proprietary. This state of affairs will result in a lot of rushed games that don't take advantage of the hardware. Then in 4-10 years we'll see what it can really do. I don't find this to be a logical state of affairs for Sony or the consumer.

You can consider that my closing point.
 
great comparison
http://www.anandtech.com/video/showdoc.aspx?i=2453&p=4


##Quote##
So what does Tim Sweeney see the SPEs being used for in UE3? "With UE3, our focus on SPE acceleration is on physics, animation updates, particle systems, sound; a few other areas are possible but require more experimentation."
##end Quote##



i dont see these arguments as geekwars it,s just different perspectives. And they make me understand machine specs more, seems like in this generation of cpu,s we see alot of different cpu types (its almost like in the 80,s)
 
Back
Top