Analysis of PS4's security and the state of hacking

You have to bring Linux and BSD, which already do MIPS, up on MIPS? Gotta be hard. If it is, they have a new ARM chip (ThunderX) with similar specs. Had to go with what was already proven and more negotiable, though, so that was MIPS.

"You never talk about what an "accelerator" is in your case..."

I referenced Octeon III as an example. Had you Googled it, you would know exactly what I was talking about. Let me help you out:

http://www.cavium.com/OCTEON-III_CN7XXX.html

The prior models, with 16 cores + accelerators, were used mostly in applications that required line-rate processing on applications like stream processing, networking, etc: CPU and I/O intensive. The low end did 24 GIPS peak and supported Interlaken (10+Gbps) w/ dedicated hardware for compression, crypto, etc.

The new models go from 24-48 cores (120-240 GIPS peak), run at 2.4GHz, do 500Gbps max I/O, offer easy integration with application-specific accelerators (500 so far) directly on network-on-chip, and have mature toolchains for Linux & RTOS's. So, you could offload compression, search (eg pathfinding), graphics, crypto, physics... whatever... onto engines that handle it at hardware speed/efficiency while letting CPU focus on everything else.

"like a "Digital Signal Processor". Modern computers already have both of those accelerators built-in. Your funky MIPS architecture doesn't add anything but dev annoyance."

You must have never programmed a Digital Signal Processor. "Funky" and "dev annoyance" are very good descriptions of it. It's like a different world compared to regular programming and with no standardization. There were whole companies founded to build tools to solve that problem. OpenCL made nice strides but it's still not regular programming. Much easier for dev's to program in C/C++, use a good concurrency approach, call a library function (SW or HW accelerated) for specific hotspots, and hit compile.

Of course, if you find that very challenging, you can always handcode several models of DSP to save yourself time. ;)

And you'd be surprised how secure you can get a game console these days from a hardware perspective. For instance, on the 360, all stacks and everything in the hypervisor is encrypted with a per boot random key and hashed as it leaves L2 for main memory. If the hash doesn't match on the way back, the system resets. You're very protected from DMA attacks. Particularly of the kind that that's easily reproducible and able to be sold in mass.

You can think of GPU cores as you schedule a series of "vector" instruction over a large chunk of data. They are great at internally paralleling this process because the flow is simple. You assume the there will be little synchronization and little branching. That's why you need such fast memory on GPUs to keep streaming data at instruction speed.

CPU cores are a lot more general prepuce where you're generally building the business logic and the work load is a lot more branch oriented.

So if you have a problem that's trivially parallizable without (much) branching logic then throwing more GPU cores is easy. Problems like this numerical in nature like large matrix calculations (math or 3d meshes), streaming data (hashing).

Hence why it's easier to keep adding GPU cores... it means games can process more geometry data in a fame, but adding more general prepuce CPU cores is harder because the complexity of business logic goes up as you split up the work and have to worry about ordering/synchronization.

You should've had a lot of fun with Cell processor if you like hackery. It blended several different models into one interesting piece of hardware that could be tweaked into emulating them all and doing some side-by-side. More interesting (and useful!) than any of the above systems. That's why supercomputer people put a cluster of them to good use. :)