| Entroper said: Most of this post supports my point. You're right that things like automatic load balancing don't "just happen" because the SPEs can only work on their local store -- all the more reason to think carefully about how your application uses memory in the design phase, and how it will give work to the SPEs.
|
You should say it differently: how it might work in connection with SPEs.
If I look at my experience, it is quite hard to determine the really processing intensive part of your program beforehand. If you put less used code to the SPEs you won't achieve drastic changes with them, that's the problem.
Yes, you might try to keep the SPEs in mind but it is simply useless to put much work into this part before you have a hlaf finished product. The real processing intensive code will grow in parts, where you didn't expect it to be, because for some difficult parts you found rather easy solutions, while some minor problems suddenly became big ones.
Most of your planning won't survive the implementation phase. In fact some of the code that you designed for the SPEs will suddenly be slower than the integrated solution.
The SPE concept has the problem, that it depends on structural parameters, not functional ones. But the structures evolve and change much faster during implementation, than the functions. In fact, if you want to protect structures you will probably get slower code, because the code around these structures will have the tendency to become more and more complex.
Yes, it is possible to design certain SPE functions beforehand, but I would presume that this code won't be used as often and as efficiently as you orginally planned. To really change the performance of the processor as a whole you have to find and export the critical functions. Cell programmers have to know Amdahl's Law by heart.
