3 ms·

I don't know, in particular concerning the game developer perspective. But from my observation, scientists who develop high-performance computing algorithms of

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.

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.