I had already spent a few years writing fragment shaders, OpenGL, and CPU vector extension code for 2D graphics acceleration, so I thought I’d have a pretty good handle on how to approach this new model of parallel programming. But trying to do anything with the SDK was just a pain. There were separate incompatible gcc toolchains for the different cores, separate vector extensions, a myriad of programming models with no clear guidance on anything… And the non-gcc tools were some hideous pile of Tcl/TK GUI scripts with a hundred buttons on the screen.
It really made me appreciate how good I’d had it with Xcode and Visual Studio. I gave up on Cell after a day.
iPhone SDk only raised the bar for the mobile industry, the rest of embedded world is still stuck in the stone age.
That architecture does have particular weaknesses when it is meant to interface with a random-access-and-deep-callstacks workflow(as would be the case using C++) - and CPUs have accrued complex cache and pipelining systems to cater to that workflow since it does have practical benefit - but the flat approach has also demonstrated success when it's used in stream processing with real-time requirements.
Given that, and the outlier success of some first-party developers, I would lean towards the Cell hardware being catastrophically situated within the software stack, versus being an inherently worse use of transistors.
As for "inherently worse use of transistors" one would have to look at how the transistors could have been used differently. The XBox360 is a different use of transistors.
That's a weird assertion for a console that sold 87M units, ranks #8 in the all-time top-selling consoles list, and marginally outsold Xbox360 which is compared against in TFA.
See: https://en.wikipedia.org/wiki/List_of_best-selling_game_cons...
> The PS3 failed developers because it was an excessively heterogenous computer; and low level heterogeneous compute resists composability.
Is cell really so different from computer shaders with something like Vulkan? I feel if a performance-competitive cell were made today, it might not receive so much hate, as people today are more prepared for its flavour of programming. Nowadays we have 8 to 16 cores, more on P/E setups, vastly more on workstation/server setups, and we have gpu’s and low level gpu APIs. Cell came out in a time when dual core was the norm and engines still did multi threading by having a graphics thread and a logic thread.
Comparing the SPEs to compute shaders is reasonable but ignores what they were for. Compute shaders are almost exclusively used for graphics in games. Sony was asking people to implement gameplay code on them.
The idea the PS3 was designed around did not match the reality of games. They were difficult to work with, and taking full advantage of the SPEs was very challenging. Games are still very serial programs. The vast majority of the CPU work can't be moved to the SPUs like it was dreamed.
Very often games were left with a few trivially parallel numerical bits of code on the SPEs, but stuck with the anemic PPE core for everything else.
Maybe in 15 years someone crazy enough will be delving in and building games that fully utilize every last aspect of the hardware. Like this person does on the N64: https://youtube.com/@kazen64?si=bOSdww58RNlpKCNp
Yes, especially exclusives like Uncharted, Demon Souls, Heavy Rain, Ni No Kuni, Metal Gear solid 4. They were definitely developed for Xbox, that version was kept secret and only the PS3 version was published due to Sony bribes.
I'd like to thank the above devs for going through the pain of developing those titles that entertained me back then...
There were some gems. I owned a PS3 and had tons of fun. Nothing in this discussion speaks directly to the entertainment value of good Sony exclusives or cross-console ports. Many people don’t care one ounce about a minor performance deficit. Deep breath.
Yeah usually only first party studios have the time, money, and access for that (Naughty Dog being a prime example thereof in the Sony universe).
Funnily enough the opposite of this did actually happen at least once: https://archive.org/details/gears-of-war-3-ps3
"a game available for both Xbox and PS3."
The "both" part means they aren't talking about exclusives.
So while PS3 was not ultimately a commercial success, it was clearly disliked by developers and the launch was certainly a disaster. I think you could argue the PS3 was a failure in many regards, and a success in some other regards. Credit to Sony, they definitely persevered through a tough launch and made it out to the other end. Nintendo wasn't able to pull off the same for the Wii U, even though it also did have some good exclusive games in the library.
[1]: https://web.archive.org/web/20161104003151/http://www.pcworl...
Lots of PS2.
Before that, only PS1's and PS2's were around.
(Belgium)
Going from such market dominance to second place is not good. Not being able to improve upon your position as the industry leader is not good. Failure might be strong, but I certainly wouldn't be happy if I was an exec at Sony at the time.
> The PS3 failed developers because it was an excessively heterogenous computer; [...]
Here is a good example: The PS3 sold only slightly more than half as many units as its predecessor, the PS2, did. Most businesses would, in fact, consider it a failure if their 3rd generation product sold much more poorly than the second generation. Sony's rapid move away from the PS3/Cell architecture gives you a pretty good reason to believe they considered it a failure too.
This does imply an architectural misstep, and one of IBM's last.
AMD vanquished IBM from the next generation of consoles.
Async DMA is important because the latency of a DMA operation is 500 cycles! But, then you remember that the latency of the CPU missing cache is also 500 cycles... And, gameplay code misses cache like it was a childhood pet. So, in theory you just need to relax and get it working any way possible and it will still be a huge win. Some people even implemented pointer wrappers with software-managed caches.
500 cycles sounds like a lot. But, remember that the PS2 ran at 300MHz (and had a 50 cycle mem latency) while the PS3 and 360 both ran at 3.2Ghz (and both had a mem latency of 500 cycles). Both systems pushed the clock rate much higher than PCs at the time. But, to do so, "niceties" like out-of-order execution were sacrificed. A fixed ping-pong hyperthreading should be good enough to cover up half of the stall latency, right?
Unfortunately, for most games the SPUs ended up needing to be devoted full time to making up for the weakness of the GPU (pretty much a GeForce 7600 GT). Full screen post processing was an obvious target. But, also the vertex shaders of the GPU needed a lot of CPU work to set them up. Moving that work to the SPUs freed up a lot of time for the gameplay code.
This happened on the PS3, too, later in its life: Sony released PlayStation Edge and middleware/engine vendors increasingly learned how to use SPU to patch over RSX being slow. At this point developers stopped needing to care so much about the composability issues introduced by heterogeneous computing, since they could use the SPUs as another function processor to offload, for example, geometry processing, without caring about the implementation details so much.
Intel reached 3.2GHz on a production part in June 2003, with the P4 HT 3.2 SL792. At the time the 360 and PS3 were released, Intel's highest clocked part was the P4 EE SL7Z4 at 3.73.
I don't think this is really an accurate description of the 360 hardware. The CPU was much more conventional than the PS3, but still custom (derived from the PPE in the cell, but has an extended version of VMX extension). The GPU was the first to use a unified shader architecture. Unified memory was also fairly novel in the context of a high performance 3D game machine. The use of eDRAM for the framebuffer is not novel (the Gamecube's Flipper GPU had this previously), but also wasn't something you generally saw in off-the-shelf designs. Meanwhile the PS3 had an actual off the shelf GPU.
These days all the consoles have unified shaders and memory, but I think that just speaks to the success of what the 360 pioneered.
Since then, consoles have gotten a lot closer to commodity hardware of course. They're custom parts (well except the original Switch I guess), but the changes from the off the shelf stuff are a lot smaller.
So the thinking was a unique architecture is what a console's raison d’être was. Of course now we know better, as the latest generation of consoles shows, butthat's where the thinking for the PS3's cell architecture came from.
exactly!
PlayStation is the one exception. But they learned the wrong lesson from the PS2 (exotic hardware is great! No one minds!) and had to get a beating during the PS3 era for the division to get back on track.
Today in 2025 the only possible advantage is maybe in a specific price category where the volume discount is enough to justify it. In general, consoles just don't make technological sense.
2600 was downright pathetic compared to TRS-80 or Apple 2
>/NES
comparable to C-64
>/Genesis
comparable to Amiga 500
I suspect a major point killing off special architectures like the PS3 was the desire of game companies to port their games to other platforms such as the PC. Porting to/from the PS3 would be rather painful if you were trying to fully leverage the power and programming model of the CELL CPU.
Many developers couldn’t afford to keep up if they had to build their own engine, let alone on multiple platforms.
Far cheaper/easier to share the cost with many others through Unreal licenses. Your fame is more portable and can use more features that you may have ever had time to add to the engine.
It’s way easier to make multi-platform engines if each one doesn’t need its own ridiculously special way of doing things. And unless that platform is the one that’s driving a huge amount of sales I’m guessing it’s gonna get less attention/optimization.
It's not that the architecture was bad, it's that it's not easily compatible to other endpoints developers wanted to release on resulting in prohibitively high costs of doing a "full" port.
Maybe that would’ve been terrible, maybe not. Kinda sounds like yes in hindsight.
But the SPU‘s were originally supposed to do the GPU work too I think. So there’s a reason the GPU doesn’t fit in terribly well, it had to be tacked on at the end so the PS3 had any chance at all. And it couldn’t be well designed/optimized for the rest of the system because they were out of time.
Did general purpose CPUs not kind of subsume this role? Modern CPUs have 16 cores, and server oriented ones can have many, many more than that
Which links to the Wiki:
> These systems gain performance or energy efficiency not just by adding the same type of processors, but by adding dissimilar coprocessors
Modern CPUs have many similar cores, not dissimilar cores.
For example, Find My's offline finding functionality runs off a coprocessor so tiny it can basically stay on forever. But nobody outside Apple gets to touch those cores. You can't ship an app that uses those cores to run a different (cross-platform) item-finding network; even on Android they're doing all the background stuff on the application processor.
Our normal desktop processors have double the cells cores. Workstation and servers have 64 or more cores.
Many core is alive and well.
maybe i dont full understand "many-core", but the definition the article implies aligns with what i think of latest qualcomm snapdragon mobile processor for example with cores at different frequencies/other differences.
also i dont understand why ps3 is considered a failure, when did it fail?
in NA xbox360 was more popular (i would say because xbox live) but ps3 was not far behind (i owned a ps3 at launch and didnt get a xbox360 till years later).
from a lifetime sales, shows more ps3s shipped globally than xbox.
The SPEs were a different instruction set with a different compiler tool chain running separate binaries. You didn't have access to an OS or much of a standard library, you only had 256K of memory shared between code and data. You had to set up DMA transfers to access data from main memory. There was no concept of memory protection so you could easily stomp over code with a write to a bad pointer (addressing wrapped so any pointer value including 0 was valid to write to). Most systems would have to be more or less completely rewritten to take advantage of them.
Early on the Xbox also did a better job with game ports. People had very little experience using multicore processors and the cell was even worse. So often the PlayStation three would have a lower resolution or worse frame rate or other problems like that.
Xbox Live is also an excellent point. That really helped Microsoft a lot.
All of that meant Microsoft got an early lead and the PlayStation three didn’t do anywhere near as well as someone might suspect from a follow up to the PlayStation 2.
As time went on, the benefits of the Blu-ray drive started to factor in some. Every PlayStation had a hard drive, which wasn’t true of the 360. The red ring of death made a lot of customers mad and scared others off from the Xbox. And as Sony released better libraries and third parties just got a better handle on things they started to be able to do a better job on their PS3 versions to where it started to match or exceed the Xbox depending on the game.
By the end I think the PlayStation won in North American sales but it was way way closer than it should have been coming off the knockout success of the PS2.
> The PS3 failed developers
It failed as an ISA (or collection thereof), and in developer mindshare.
I wonder what the REDACTED piece means here, aren't the PS3 hardware specifications pretty open? Per Copetti, the RSX memory had a theoretical bandwidth of 20.8 GB/s, though that doesn't indicate how fast the CPU can access it.
It is a mind bendingly tiny 16MB/s bandwidth to perform CPU reads from RSX memory.
I didn’t realize DMA didn’t help with GPU memory.
PS1: Easy to develop for and max out. PS2: Hard to develop for and hard to max out. PS3: Even harder than PS2. PS4: Back to easier. PS5: Just more PS4. PS5 PRO: Just more PS5.
For whatever reasons developers seem loath to talk about how difficult developing for a given console architecture is until the console is dead and buried. I guess the assumption is that the console vendor might retaliate, or the fans might say, "Well all of these other companies are somehow doing it, so you guys must just suck at your jobs."
An early interview with Shinji Mikami is one of the only ones I can recall about a high-profile being frank about having difficulties developing for the console[0]:
> IGNinsider: Ahh, smart politics. How do you feel about working on the PlayStation 2? Have you found any strengths in the system by working on Devil May Cry that you hadn't found before? > > Mikami: If the programmer is really good, then you can achieve really high quality, but if the programmer isn't that great then it is really hard to work with. We lost three programmers during Devil May Cry because they couldn't keep up.
[0] https://www.ign.com/articles/2001/05/31/interview-with-shinj...
The PlayStation did so well a lot of people wanted the PlayStation 2. And because it worked as a cheap DVD player it sold extremely well.
Sony learned hard to program expensive exotic hardware does great!
PS3 arrives with hardware that’s even more expensive and even harder to program and gets a world of hurt.
So for the PlayStation 4 they tried to figure out what went wrong and realized they needed to make things real easy for developers. Success!
PlayStation 5, that PlayStation 4 four thing worked great let’s keep being nice to developers. Going very well.
The PS2 succeeded _in-spite_ of its problems. And Sony didn’t realize that.
Having never worked on SPE coding, but having heard lots about interesting aspects, like manual cache management, I was very interested to read more.
> C++ virtual functions and methods will not work out of the box. C++ encourages dynamic allocation of objects but these can point to anywhere in main memory. You would need to map pointer addresses from PPE to SPE to even attempt running a normal c++ program on the SPE.
Ah. These are schoolboy errors in games programming (comparing even with the previous 2 generations of the same system).
I think the entire industry shifted away from teaching/learning/knowing/implementing those practices de rigeur, so I'm absolutely not criticising the OP -- I was taught the same way around this time.
But my reading of the article is now that it highlights a then-building and now-ubiquitous software industry failing, almost as much as a hardware issue (the PS3 did have issues, even if you were allocating in a structured way and not trying to run virtual functions on SPEs).
The only pratical many-core I know of was the SPARC T-1000 series https://en.wikipedia.org/wiki/SPARC_T_series
>The original design was approximately 4 Cell processors with high frequencies. Perhaps massaging this design would have led to very homogenous high performance Many-Core architecture. At more than 1 TFlop of general purpose compute it would have been a beast and not a gnarly beast but a sleek smooth uniform tiger.
That's great and all, but the PS3 cost (famously) FIVE HUNDRED AND NINETY NINE US DOLLARS (roughly $900 dollars in todays money).
However one thing I noticed is that multi-core programming in 2006 was absolutely anemic. Granted I was too young to actually understand what was happening at the time, but a couple years ago I went in on a deep dive on the Cell and one thing I came away with was proper parallelism was in its infancy for mainstream development. Forget the Cell, it took a long time for game developers to take advantage of quad core PCs.
Developers were afraid of threads, didn't understand memory barriers and were cautious of mutexes. Gaben has a famous clip trashing the PS3 because most of valve's developers at the time did not have the experience programming multicore systems. It was common to just have objective-based threads (ex, Render thread, AI thread, Physics thread), and pretend coordination didn't exist for large parts of the code. This mostly worked up until you had more cores than threads. This stands in stark contrast to most parallel thread today that does userspace scheduling with tasks or threads.
Even Naughty Dog eventually figured out late in the cycle to best take advantage of SPEs using fibers with a system that looks like modern async reactors (like node or tokio) if you squint really, really hard.
The Cell was just really really early. Looking back I don't think the Cell was half-baked. It was the best that could be done at the time. Even if the hardware was fully baked, there was still 5-10 years of software engineering research before most people had the tooling to tae advantage of parallel hardware.
Well, if anyone was going to figure it out, it would've been Naughty Dog, they've got a long history of being absolute wizards at taming Sony's hardware.
Do you have any links to further details about ND's achievements on the PS3? I found a talk that looked like it might cover the issue, but it seems like it's about the PS4. https://gdcvault.com/play/1022186/Parallelizing-the-Naughty-...
I'll try to find it, but admittedly this is knowledge that I researched back in ~2011 around the time of Uncharted 3's launch.
Compared to today, the Cell really isn’t so complex — we have just as many or more cores, we have GPU programming (and low level APIs with manual data moving and what not). It’s just that the cell came out in a world where dual core had just became the norm and people hadn’t really accustomed to it yet. It was ahead of its time. And a new architecture meant immature tooling.
I also thought the price was OK considering the Blu-ray support.
I'd like to see a list of the top-selling consoles with their inflation-adjusted prices. The ps3 did really well considering the price. I'd say the ps2 hit the sweet spot for price while still offering a performance improvement over the previous generation.
OpenMP was around back then and was easy.
A lot of people brought them just for that, same thing with DVDs and PS2s.
> The PS3 failed developers because it was an excessively heterogenous computer
Most here are probably too young to realize the PS3 was supposed to be a flagship consumer device to show off the Cell processor and Sony was pushing hard for the Cell arch to be everywhere, media devices, general purpose computers, next gen supercomputers
It died hard when people realized how difficult it was to program for, and I dont think anything else other than the PS3 ever bothered seriously trying again with that arch.
Yes it did, fairly near the top.
>>It is important to understand why the PS3 failed.
This article is a bunch of nonsense.
> It is important to understand why the PS3 failed.
Full disclosure: I have been doing The Internet for well over 30 years. :)
"including the title" was intended to attach to the line count. Some may include the page title (h1 heading in HTML) in the lines at the start of the page. Some may not, because the title isn't necessarily part of the article itself. I was trying to disambiguate.
I was not trying to say that the "PS3 failed" was in the title.
You're right that it's in the URL but I didn't see that until you pointed it out.
Being pedantic is not an interesting position.