Hacker News Reader

Comment by pavlov | Hacker News Reader

I remember trying to learn Cell programming in 2006 using IBM’s own SDK (possibly different and less polished compared to whatever Sony shipped to licensed PS3 developers).

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.

View on HN

Yea, this was the horrible world of embedded programming and working with SoCs before the iPhone SDK finally raised the bar. BSPs composed of barely-working cobbled-together gcc toolchains, jurassic-aged kernels, opaque blobs for flashing the devices, incomplete or nonworking boot loaders, entirely different glue scripts for every tiny chip rev, incomplete documentation. And if you wanted to build your own toolchain? LOL, good luck because every gnu tool needed to be patched in order to work. It was a total mess. You could tell these companies just made chips and reference systems, and only grudgingly provided a way to develop on them. iPhone and Xcode was such breath of fresh air. It pulled me out of embedded and I never went back.

>Yea, this was the horrible world of embedded programming and working with SoCs before the iPhone SDK finally raised the bar.

iPhone SDk only raised the bar for the mobile industry, the rest of embedded world is still stuck in the stone age.

Modern ARM microcontrollers apparently use standard GNU toolchains shipped by my Linux distribution. Developing software for a Cortex M0+ was a really good experience. Lack of a complete device emulator made it hard to debug at times but I dealt with it.

Stop! You're giving me flashbacks of developing for Hypercom point of sale devices! Never again will I work with alpha software so buggy it only worked from bundled samples! One had to remove their widgets from a sample, one at a time, testing at each step, then adding your own one at a time. Otherwise it would break something and you'd have to start over.

So this is why so many cash registers are now iPads.

I didn't gain direct experience with Cell, but given that description of the tooling, I'm unconvinced that the issue is fundamental to many-core, or that the author's assertion of non-composability holds up under scrutiny. Composition in "flat" processing architectures is, in principle, exactly what is already seen on a circuit diagram. It recurs in the unit record machines of old, and in modern dataflow systems.

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.

The outlier success of some first-party developers indicates that focus and talent on this exotic hardware was required to demonstrate its fully potential. As they say this was an "expert friendly system" and this was because it was complex and it was complex because it was heterogenous.

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.

Reply on news.ycombinator.com