4 ms·
It wasn't due to the POWER architecture, it was the SPEs, which were not based on POWER. The biggest problem for compilers and developers of the day was the fac
by trsohmers 11y ago
It wasn't due to the POWER architecture, it was the SPEs, which were not based on POWER. The biggest problem for compilers and developers of the day was the fact that each of the SPE cores had their own local memory ("scratchpad") that is similar to a cache, but is not hardware managed.
My company (REX Computing) is working on a new processor architecture that is built around scratchpad memory... the main benefits of a scratchpad are that it is lower latency (which basically means faster), uses less area and power, and can be built into larger arrays than your regular hardware managed caches. The big drawback, as seen by Cell, is the fact that it is difficult for most programmers to manually manage their memory.
Our big advancement is that we've developed new compiler techniques (which have been DARPA funded), that would not only make it a lot easier to program the Cell architecture, but allows us to go even further than they did with Cell in making a highly parallelized and energy efficient processor.
- scott_s 11y agoI'm very interested in reading any public information you have on this work.
- trsohmers 11y agoWould love to share more info, but I should have stated that it won't magically make Cell simple to program for... our new compiler techniques are dependent on a lot of new architectural ideas we have implemented in hardware, and while we would solve the memory cramming problem (Trying to fit your application into the fixed scratchpad space) on many architectures (Cell, TI DSPs, a lot of other embedded chips), the real magic we have developed is in being able to have 90%+ of it statically scheduled, which we're only able to do with our architecture. If you're interested, check out our website (http://rexcomputing.com http://rexcomputing.com) and sign up for the mailing list... The only thing we have public is a very vague and more technique overview paper in general rather than a real description of what we are doing(http://memsys.io/wp-content/uploads/2015/09/p98-sebexen.pdf http://memsys.io/wp-content/uploads/2015/09/p98-sebexen.pdf). It presented at a conference earlier this month (and to be published by the ACM), but I hope to give more details on our specific implementation and other cool features later this year. If you're willing to sign a NDA, feel free to use the contact us on the website though.
- protomyth 11y agoActually, I wasn't referring to the SPEs, I specifically heard the POWER architecture had some stuff that made it hard to implement and slower than other RISCs.
- cbsmith 11y agoAs was aptly demonstrated by x86 systems (both now and in that era), transistor budgets had grown enough by the time Cell came of age that the impact of ISAs could have on overall performance was comparatively trivial. POWER had a lot of funny things about it, but it wasn't that hard to get POWER architectures to move quickly.
- protomyth 11y agoYou still have to implement the spec, and my question is about the spec. Yes, we can overcome crap which let us end up with the least liked ISA for the winner.
- cbsmith 11y agoPOWER inherited a lot of baggage from the IBM R/T, the first real go at RISC, so it was the most un-RISC-like of the RISC ISA's. That was the included all the addressing modes and a surprisingly rich ISA. Those were all considered no-no's for unlocking the advantages of RISC.
- protomyth 11y agoThanks. Is there a document / blog post that tells exactly what the baggage and addressing modes were? I've heard the problem but never found the actual specifics.
- cbsmith 11y agoWell, a fairly handy reference might be the PowerPC 601 ISA docs: http://www.freescale.com/files/32bit/doc/user_guide/MPC601UM.pdf http://www.freescale.com/files/32bit/doc/user_guide/MPC601UM... Chapter 3 touches on memory addressing modes. The 601 was more compatible with the full POWER ISA that came before it, but looking at the docs for the POWER ISA itself would probably be more instructive.