4 ms·

> Reminds me slightly of the Cell processor, with its dedicated SPUs for fast processing, orchestrated by a traditional CPU. But we all saw how successful that

> Reminds me slightly of the Cell processor, with its dedicated SPUs for fast processing, orchestrated by a traditional CPU. But we all saw how successful that was (: The success of the Cell is more subtle: - (It seems many) game developers hated it because it is so different to program than other CPUs of other game consoles of its time (in particular the CPU of the Xbox 360). For game studios, time to market and portability of the game to other consoles is important. - On the other hand, scientists who ported their high-performance numerical computations to the Cell seem to have loved it. Such software is often custom-built for the underlying hardware, and here cost (of the hardware) and possible speed are the measures on which to evaluate the hardware. Here the Cell processor of a PS3 cluster was much more competitive than other available solutions (GPGU did not really exist at this time).

cedilla 2y ago
Gabe Newell of Valve famously hated the Cell architecture, and I think that's very illustrative. He is of the generation of game devs that was very willing to try wild algorithms and hand-massage assembly and use all tricks to get 3D fast, so the PS3 should have been a perfect fit. But he did not like to have to start back at square one.
amelius 2y ago
Isn't that because game developers use conditional statements more, and scientists typically have a flow-graph that describes a computation and this computation doesn't have conditional parts? So it is a more natural fit?
- aleph_minus_one 2y ago
  I don't know, in particular concerning the game developer perspective. But from my observation, scientists who develop high-performance computing algorithms often think much deeper about the mathematical structure of their problems than game developers do. I thus have a feeling that what you describe as "flow-graph that describes a computation" is rather a result of this deep analysis. I can easily imagine that this would partly also work for video games, but I would hypothesize either this is too much work that is not really rewarded in the game industry (the game industy is known ("crunch time") for having to churn out lots of new code fast), or if you are a lot into this kind of thinking, the game industry might not be the most rewarding place to work at.
  - exe34 2y ago
    a game developer might have an algorithm that they have to implement. a computational scientist might find an alternative algorithm that makes different still-acceptable tradeoffs and yet fit more naturally in a new arch.
    - amelius 2y ago
      On the other hand, the game dev might just make the graphics slightly less realistic, whereas the scientist has to simulate the true physical equations.
      - aleph_minus_one 2y ago
        > whereas the scientist has to simulate the true physical equations. Every model of nature is an approximation. In high-performance computing, it is often a serious tradeoff where to "cut corners" to make the computation even feasible (e.g. - Which grid size or tesselation do we use? - Do we use a more regular grid to make use of optimizations or do we use a more irregular grid/tesselation for more precision at the places where it matters? - Do we use a simpler or more sophisticated model? - For multi-scale problems: do we compute each scale individually and combine the results? - etc.). EDIT: In my opinion the central difference to game development is that in science each such possible optimization where one might cut corners has to be deeply analyzed. Simply using an easy, pragmatic shortcut that "looks sufficiently good" is rarely possible in science.
  - rbanffy 2y ago
    The flow graph approach is also relevant if you want to keep track of rounding errors of your floating point operations. Every float is actually an interval (containing all possible real numbers in it) and you might want to keep track of the size of the intervals along with the numbers you get from the floating point units.

cedilla 2y ago

Gabe Newell of Valve famously hated the Cell architecture, and I think that's very illustrative. He is of the generation of game devs that was very willing to try wild algorithms and hand-massage assembly and use all tricks to get 3D fast, so the PS3 should have been a perfect fit. But he did not like to have to start back at square one.

amelius 2y ago

Isn't that because game developers use conditional statements more, and scientists typically have a flow-graph that describes a computation and this computation doesn't have conditional parts? So it is a more natural fit?

aleph_minus_one 2y ago
I don't know, in particular concerning the game developer perspective. But from my observation, scientists who develop high-performance computing algorithms often think much deeper about the mathematical structure of their problems than game developers do. I thus have a feeling that what you describe as "flow-graph that describes a computation" is rather a result of this deep analysis. I can easily imagine that this would partly also work for video games, but I would hypothesize either this is too much work that is not really rewarded in the game industry (the game industy is known ("crunch time") for having to churn out lots of new code fast), or if you are a lot into this kind of thinking, the game industry might not be the most rewarding place to work at.
- exe34 2y ago
  a game developer might have an algorithm that they have to implement. a computational scientist might find an alternative algorithm that makes different still-acceptable tradeoffs and yet fit more naturally in a new arch.
  - amelius 2y ago
    On the other hand, the game dev might just make the graphics slightly less realistic, whereas the scientist has to simulate the true physical equations.
    - aleph_minus_one 2y ago
      > whereas the scientist has to simulate the true physical equations. Every model of nature is an approximation. In high-performance computing, it is often a serious tradeoff where to "cut corners" to make the computation even feasible (e.g. - Which grid size or tesselation do we use? - Do we use a more regular grid to make use of optimizations or do we use a more irregular grid/tesselation for more precision at the places where it matters? - Do we use a simpler or more sophisticated model? - For multi-scale problems: do we compute each scale individually and combine the results? - etc.). EDIT: In my opinion the central difference to game development is that in science each such possible optimization where one might cut corners has to be deeply analyzed. Simply using an easy, pragmatic shortcut that "looks sufficiently good" is rarely possible in science.
- rbanffy 2y ago
  The flow graph approach is also relevant if you want to keep track of rounding errors of your floating point operations. Every float is actually an interval (containing all possible real numbers in it) and you might want to keep track of the size of the intervals along with the numbers you get from the floating point units.