4 ms·

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

by pavlov 2y ago

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.

ryandrake 2y ago
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.
- FirmwareBurner 2y ago
  >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.
  - matheusmoreira 2y ago
    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.
- paulryanrogers 2y ago
  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.
  - chasil 2y ago
    So this is why so many cash registers are now iPads.
crq-yml 2y ago
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.
- petermcneeley 2y ago
  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.

by pavlov 2y ago

ryandrake 2y ago

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.

FirmwareBurner 2y ago
>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.
- matheusmoreira 2y ago
  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.
paulryanrogers 2y ago
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.
- chasil 2y ago
  So this is why so many cash registers are now iPads.

crq-yml 2y ago

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.

petermcneeley 2y ago
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.