What made Cell different
Sony, Toshiba and IBM built the Cell Broadband Engine together. IBM Research's published abstract describes it as a multicore system-on-a-chip. It paired a main PowerPC core with several Synergistic Processing Units (SPUs). IBM's technical literature calls the main core the PPE and the others SPEs. The PS3 version is generally described as one PPE with eight SPEs, and IBM's design paper does not say how many were enabled in the console.
IBM's abstract also lists the design priorities: maximum performance, minimal chip area and minimal power. The first target application was real-time systems that need very fast data movement and fast compute.
Cell wasn't simply a "bad CPU." It was a heterogeneous design. Performance depended on whether developers split work sensibly between the general-purpose core and the specialized ones. That is "great when developers target them well and painful when emulation has to recreate that behavior on a different architecture."
The popular claim that PS3 games generally ran worse than Xbox 360 versions is repeated in many retrospectives. I couldn't corroborate it from primary sources, so treat it as a common characterization rather than settled fact. The same goes for launch pricing and early hardware failure rates. Those details belong to console history rather than emulation.
Why emulation is hard
A PC CPU runs x86-64 code, or Arm64 on newer machines. The PS3 expects a PowerPC core plus SPUs that behave differently from ordinary PC cores. Several write-ups on the subject describe the mismatch the same way. SPUs relied on local store memory and highly parallel SIMD operations. Modern CPUs don't naturally mirror that model.
Those write-ups also say RPCS3 handles this by recompiling code. It uses LLVM and ASMJIT backends to turn Cell instructions into x86 code. The quality of that translation determines how much host CPU time each emulated SPU operation costs.
This is my reading of the architecture, supported by the commentary above rather than by RPCS3's own compatibility documentation. It also explains why PS3 emulation leans so heavily on the processor rather than the graphics card. One setup guide says RPCS3 depends on the CPU far more than the GPU because recompiling SPU code in real time is so demanding.
Where RPCS3 stands now
The RPCS3 project maintains a public compatibility list and publishes monthly statistics. Its wiki was last edited on September 30, 2026. The September 2026 row reads:
| Status | Entries |
|---|---|
| Playable | 2,809 |
| Ingame | 721 |
| Intro | 31 |
| Loadable | 2 |
| Nothing | 0 |
| Total | 3,563 |
The MakeUseOf article says "over 80%" of the library is playable. The project's own numbers give 2,809 of 3,563, or about 78.8%. That is close to the claim but not over 80%.
The unit of counting also matters. The project tracks compatibility per Game ID and media type, not per game title. Disc and digital releases of the same game have separate entries. The wiki also notes that the list was restructured over time. Merged regional entries, dropped online-only titles and removed non-game entries all changed the totals. So this isn't a simple count of unique games.
The history is still striking. In February 2017, the list showed 94 playable entries out of 1,557. By December 2017 it showed 783 out of 3,101. By September 2026 it showed 2,809 out of 3,563. The "Nothing" category has been at zero since late 2021, with brief exceptions.
Recent months show continued gains. Playable entries rose from 2,693 in July 2026 to 2,758 in August and 2,809 in September. Over the same stretch, Ingame entries fell from 805 to 721, and Intro entries fell from 60 to 31.
What "Playable" does and doesn't mean
"Playable" is a project status, not a performance guarantee. RPCS3's FAQ says support for commercial games varies and points users to the compatibility list for any particular title. It also says more games become playable as hardware and firmware emulation becomes accurate enough.
Several things follow from that:
- Check your exact release. Status is recorded per Game ID, so a disc edition's rating may not apply to a digital edition.
- Expect CPU dependence. Cell-heavy titles can stress the host processor more than other games. One setup guide says a CPU with strong per-core performance matters more than raw core count.
- Expect first-run stutter. On a game's first launch, RPCS3 compiles PPU and SPU code and caches shaders as they appear, which causes hitching.
- Don't treat old FAQs as current. RPCS3's FAQ page was last edited in April 2020. Its system requirements and platform notes, such as saying macOS isn't supported, are out of date. Use the live compatibility list and current project documentation instead.
Optimization is still moving
Recent reporting suggests progress hasn't stalled. Several outlets covered an RPCS3 SPU optimization effort. They say lead developer Elad identified previously unrecognized SPU usage patterns and added new code paths that generate more efficient output. One account says the team reported a 5% to 7% average FPS improvement between two development builds, using the SPU-heavy game Twisted Metal as the test.
Those figures come from secondary aggregators, not RPCS3's own release notes, so treat them as indicative. They do show what the work looks like. It is mostly incremental gains in how Cell code is translated, not a single breakthrough that "solves" the console.
The takeaway for PC users
- Cell rewarded developers who tuned for it, but it was an awkward target for conventional CPU assumptions.
- Emulation costs the host CPU a lot of work, and that work is hard to avoid.
- RPCS3's September 2026 list shows 2,809 playable entries out of 3,563. That is about 79%, counted by Game ID rather than unique title.
- Before planning a build around a specific game, look up its exact Game ID on the live compatibility list.
The headline is mostly right about why PS3 emulation took so long. The accurate picture is more nuanced. Progress has been enormous, but it is measured in project statuses, not a promise that every game runs smoothly on every PC.