There are now architectures other than CPUs that matter. GPUs, mostly. "AI chips" are coming. And, of course, Bitcoin miners. All are massively parallel. What hasn't taken off are non-shared-memory multiprocessors. The Cell was the only one ever to become a mass market product, and it was a dud as a game console machine.
I've read that Sony was under the impression that the licensing agreement meant that IBM would market Cell tech to other customers, those customers being in other computer markets like datacenters and stuff, rather than to Microsoft, for the 360, at the same time that the PS3 was still in development.
"As the book relates, the Power core used in the Xbox 360 and the PS3 was originally developed in a joint venture between Sony, Toshiba and IBM. While development was still ongoing, IBM–which retained the rights to use the chip in products for other clients–contracted with Microsoft to use the new Power core in their console. This arrangement left Sony engineers in an IBM facility unknowingly working on features to support Sony’s biggest competitor, and left Shippy and other IBM engineers feeling conflicted in their loyalties."
from http://gamearchitect.net/2009/03/01/the-race-for-a-new-game-...
(it's a book, and worth reading)
In 2007, Gabe Newell famously complained that the Cell was "a waste of everybody's time. Investing in the Cell, investing in the SPE gives you no long-term benefits. There's nothing there that you're going to apply to anything else. You're not going to gain anything except a hatred of the architecture they've created."
This was a different time. At that time researchers tried to build clusters out of PS3s - because the speed advantages of the Cell made it worth and "regular" Cell clusters were much more expensive. Some years later GPGPU became feasible and one could forsee that it will become faster than the Cell, too, in near future - and at that time the same kind of researchers dropped their PS3 clusters and built GPGPU clusters. Don't tell me that particular in the beginning GPGPU was easier to program for than the Cell.
It was also the time when Apple switched to Intel CPUs. I know at that time IBM was also trying to sell the Cell to Apple, but Steve Jobs refused and decided for Intel instead.
This decision of Apple and the decisions of researchers to stop tinkering with PS3 clusters and build GPGPU clusters instead were in my opinion the two landslides after which the fate of the Cell was destinied.
> Don't tell me that particular in the beginning GPGPU was easier to program for than the Cell.
The alternative was to use bog-standard homogeneous cores.
Yes, the air force bought a compute cluster of PS3s for some specialized calculations. I wouldn't read too much into that. It says little about the suitability of the architecture for more general purpose computing. Supercomputers were always weird.
> It was also the time when Apple switched to Intel CPUs.
I don't believe there was much chance of Apple moving to Cell. Their switch to Intel was because IBM could no longer seriously compete outside of a few niches. There's nothing positive to infer from IBM's unsuccessful pitch to Jobs.
> This decision of Apple and the decisions of researchers to stop tinkering with PS3 clusters and build GPGPU clusters instead were in my opinion the two landslides after which the fate of the Cell was destinied.
You're assigning far more importance to research group purchases than I think is warranted. They don't buy enough to create economies of scale. That's why researchers so frequently adopt consumer products already manufactured at scale, like the Novint Falcon, Microsoft Kinect, and gaming graphics cards.
The Cell was best-in-class for a few specialized use cases, but it was never going to take the world by storm. If we turn to a heterogeneous architecture in the future, it will be begrudgingly, after all simpler alternatives have been exhausted.
This is true, but in the consequences I have to disagree: Very often from this kind of "abusing" consumer products for research purposes there emerge quite interesting applications that do become quite popular and economically important. For example from such research there came the idea to use the Kinect as a 3D scanner - from this commercial applications emerged. Or from GPGPU (which at the beginning NVidia was quite the opposite of enthusiastic about) CUDA and later OpenCL emerged (which is much better to program for than abusing vertex and fragment shaders).
That is why I considered it is quite important for the future of the Cell when researchers went from tinkered PS3 clusters to GPGPU and called this a "landslide event for the future of the Cell".
So it's only useful for tasks that work like an assembly line - data flows in sequentially, gets processed, and output is pumped out. Great for audio. Lousy for everything else in games.
If you had 16MB on each CPU, the little CPUs might be useable. You might be able to run physics or pathfinding or NPCs in one.
The Cell demanded you to structure your program around small tasks that could be run in parallel across its seven vector cores. There's no getting around the fact that it's the programmer who has to break down problems to be small enough to fit on those cores without letting coordination overhead get out of control.
In the end, people just made each SPE do a single task, like dedicate one to audio, one to geometry, etc. There is not really enough parallelism like this in most software to support a cell-like approach now that even consoles get >4 real cpu cores. Real caches are the norm because they are extremely useful for programmers.
The villainy of IBM was just a slight additional problem over just how terrible cell was from a software standpoint.
The thing that made the Cell what it was, namely the 7 SPE units, were not used in the Xbox 360.
The cell processor was intended to be the graphics solution for the PS3 [1]. The story I heard was that Sony was a hardware company and its engineers wanted technology that would work for new digital television applications and believed that the cell was going to be the perfect solution for everything, with its 8 "cpus". Except nVidia. Turns out a GPU is better at graphics than even eight very fast cpus. The PS3 wasn't going to have a GPU, and then they saw some Xbox 360 demos and had a brown pants moment. So they added a GPU at the last minute.
[1] https://www.criticalhit.net/gaming/a-brief-history-of-the-playstation-3/You would make a killing with a CPU twice or ten times as fast. Many algorithms are only suited for single-core operation. I don't know if this will ever change. The focus has shifted to other architectures mostly because we've reached a ceiling for single-core CPU.
Heck, current x86 chips could be juiced quite a bit if you could take out the requirement for backwards compatibility. Instruction encoding being the obvious thing (not that it's not hip and RISC, but that it's an absolute mess that a huge proportion of the chips power has to be wasted on, and is pretty space-inefficient due to how horribly allocated things are). Less obviously just removing things like the data stack instructions (which, at least on Intel, have a dedicated "stack engine" to optimize them), the ability to read/write instruction memory directly (creates a mess of self-modifying code detection to maintain correct behaviour, and complicates L1 cache coherency a bit). Trimming transistors reduces the power consumption, which in turn means you can raise the voltage without the chip melting, and can clear up space in your critical data path.
On smaller low power cpus it is more significant of course.
The stack engine is necessary anyway even if you have no specific stack instructions, as it removes the dependence of the top of stack manipulation from local variable accesses which is critical. Explicit stack manipulation instructions might actually make the stack engine simpler.
Coherent instruction cache and pipeline are super relevant in this age of pervasive self modifying code (a.k.a JIT).
Modern CPUs are complex for a reason.
Barriers are expensive. JITs might need to issue lots of them. Then the next generation of CPUs start tracking modified lines to make barriers cheaper. Then you end up with all the hardware complexity of implicit barriers without simplifying the software side.
> JIT compilers that target other architectures already satisfy this requirement.
they might have different tuning parameters to take into account the cost of the barrier when deciding profitability of JITing a region of code.
> Only backwards compatibility with existing x86 software requires a coherent instruction cache.
Far from it, IIRC the coherency guarantee has actually been strengthened recently. It used to require a far jump as a barrier.
Explicit vs implicit barriers are just an architectural tradeoff.
None of the changes to x86 people have thought of over the years really helps enough to break backcompat. Simply because they aren't on the fast path on the critical execution stage. The limit imposed on frequency by power in current cpus is not really the total amount of power consumed, it's the amount of power consumed in the <0.25mm of chip that houses the register file, forwarding network and alus. That is, the place were things actually happen during the most important pipeline stage. This is why a 8-core cpu running just a single thread cannot make one of the cores consume as much power as all the 8 would if running 8 threads -- the register file of the running core would just melt, even if the total power would stay below chip limits.
x86 decoding is hairy and takes a long time and a lot of transistors. However, it is placed in it's own pipeline stages, that are ran parallel to the execute and only slow it down by making a branch miss a little more expensive. And the power is limited today by caching the decoded uops in their own cache, so during any tight loop, the decode hardware is idle and consumes no power. The same sort of goes for the stack engine -- as it runs early in the pipeline, it is basically a way to compress instructions a little that saves power by making code more compact when it is running, and does nothing when it is not used. Removing it would not really help, even if all code instantly changed to accommodate. Much of the rest of the ugly warts of the x86 architecture is handled in the time-honored CISC way: just punt it to microcode, performance be damned. Today, self-modifying code technically works, but you never want to do it because invalidating lines in the L1i has been implemented in the way that is the fastest and cheapest way to make the common case of code that does not modify itself. (And which has to exists even if you don't support self-modifying code, because there has to be some way of invalidating L1i entries.) Similarly, a lot of the CISC instructions that make more sense to implement as software routines (fpu sin/cos for example) are today just abandoned ucode routines that are slower than rolling your own.
Also, I don't think the trouble with added complexity out of the hot path is any added latency, it's that they're needlessly burning up the thermal budget. Not that raising the voltage is the best way of increasing frequency, but it's sure to do so.
It's worse than that. A 3GHz version of Northwood was released a little over fifteen years ago. I doubt it was the first 3GHz processor (that'd be a PPC or something?), but it's definitely symbolic...
(And a 5.2 GHz S/390-arch CPU in 2012 too)
Note that the following generation of POWER was clocked lower. Clock frequency != performance.
Systems running on AWS Lambda or Kubernetes or Kafka might also count as non-shared-memory multiprocessors.
There was a time about--maybe a bit over--10 years ago when there were a whole lot of distributed memory processors/systems/hybrids coming onto the market. SciCortex, BlueGene, Cell, Azul, Tigera (I think) coming onto the market, as well as SMP chips like Sun's Niagara. The general problem is that, by the time these specialized designs would get to market, Moore's Law would have turned another crank and made all the work moot.
I do think with CMOS scaling slowing down/dying, we'll see more specialized designs even if they're a pain for programmers and system architects because what choice do we have? We already see it with GPUs, FPGAs, and so forth.
There are ways to do it even passively but none of them are light weight. Fast small fan(s) and heat pipes are probably the lightest.