7 ms·

A Programming Language for Games, Talk #2 [video]

51 points by bluehex 12y ago

bluehex 12y ago
Talk one is here: https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ https://news.ycombinator.com/item?id=8342697 https://news.ycombinator.com/item?id=8342697
archagon 12y ago
Kind of a tangent: Mainly on Jonathan Blow's account, I've been watching a number of similar talks by low-level programmers — for example, Mike Acton's "Data Oriented Design"[1] — and following others on Twitter. I've noticed that much of the time in these presentations, there seems to be a level of disdain towards programmers who don't optimize things down to the bit. (For example, Acton follows a dozen slides on minute cache optimization — featuring assembly examples — with "Bad programming is easy" and "Design patterns are spoonfed material for brainless programmers incapable of independent thought...") This really bothers me. On the one hand, people like Blow and Acton are working on some of the most complicated software in the world, so I have to give them all my respect. At the same time, this programming style is so alien to me that I simply can't make sense of Acton's patterns and optimizations from a cursory glance. (Blow's examples from AAA development similarly disturb me, though they're much more comprehensible.) This is not what got me into programming, and yet these presentations by coders I respect make me feel like I'm a dummy who's completely "doing it wrong". I get the feeling that there's a whole separate world of these low-level, performance-optimizing developers who've shrugged off the mainstream and have their own, parallel outlook on how programming should be done. Much of the time, their ideas are very interesting to me. But I don't know how to reconcile their methodology with mine, which works on a much higher level and makes iteration and development so fun and easy — even if things like OO and design patterns bite me in the butt sometimes. I know that many of us here, spoiled by web and app development, must feel the same way. Is this sort of ascetic, hardware-savvy code really what "good programming" looks like? Because I want to get better at my craft, but it just looks like a whole lot of pain. [1]: http://www.slideshare.net/cellperformance/data-oriented-design-and-c http://www.slideshare.net/cellperformance/data-oriented-desi... Off-tangent, I am enjoying these lectures from an academic point of view, even though I don't think I would have a use for this hypothetical language!
- ps4fanboy 12y ago
  Agree with you, however if you watch blows talks he is very clear that he says a lot of these problems are very specific to games. And its games that really benefit from these low level optimizations.
- jamii 12y ago
  I really enjoy reading the Bitsquid blog (two guys who made a game engine and sold it to autodesk). They have a much more balanced take on the subject (eg http://bitsquid.blogspot.com/2011/12/pragmatic-approach-to-performance.html http://bitsquid.blogspot.com/2011/12/pragmatic-approach-to-p...) and lots of practical examples (eg http://bitsquid.blogspot.com/2012/09/a-data-oriented-data-driven-system-for.html http://bitsquid.blogspot.com/2012/09/a-data-oriented-data-dr... , http://bitsquid.blogspot.com/2014/08/building-data-oriented-entity-system.html http://bitsquid.blogspot.com/2014/08/building-data-oriented-...). There are benefits not just to performance but to clarity and debuggability. It becomes much easier to figure out where your program is spending time or where data is being corrupted because work is done in large, homogeneous chunks instead of being spread all over the stack trace.
  - NickPollard 12y ago
    The Bitsquid developers are very, very savvy programmers and I find myself agreeing with almost all the design decisions they made in their engine - in fact, my engine uses a lot of similar patterns and constructs. I wasn't aware they had sold to Autodesk though.
- dkarapetyan 12y ago
  Understanding the entire stack is in general a good thing but you're looking at it wrong. These guys are good programmers but they have spent decades doing this stuff so comparing yourself to them is a completely unfair comparison. Plus, like everyone else they are not objective observers and have a bias when it comes to expressing their opinions on this stuff. If all you do day in day out is optimize low level code then of course you are going to attach more value to low level optimizations and machine level understanding. Now contrast this with the likes of Alan Kay, Bob Harper, Benjamin Pierce, etc. and you notice the same pattern. These people couldn't care less about the low level details and instead espouse the benefit of high level theoretical understanding and how such knowledge advances the field. Both viewpoints are correct and balancing those two viewpoints is where the engineering aspects of software engineering come into play.
implicit 12y ago
About 23 minutes in, Mr. Blow says that lambdas has "questionable performance," but the actual cost is relatively predictable. Current C++ compilers will try to inline lambdas. Mr. Blow's specific example will be inlined by both g++ and clang, (I haven't tested MSVC) depending on the optimization level you set. std::function does introduce overhead, and the reason why is important: How can you implement an array of lambdas that all accept the same signature, but close over different kinds of environments? You need to be able to copy and destruct those environments without static knowledge of how big they are and what's in them. std::function makes this work by allocating the environment on the heap and hiding it from the type signature. If you are averse to this extra overhead, there's a really easy rule to follow: Until you actually explicitly write "std::function" in your code, you do not pay its cost. I know a few ways around this: If you always use auto when dealing with function-local lambdas, you don't pay any extra overhead. You can think of each lambda as being the sole instance of a struct that contains the environment to be closed over, plus a non-virtual method. Just be aware that no lambda is type-compatible with any other. (exception: two lambdas are type-compatible if they have empty environments and the same type signature) You can templatize lambda-consuming functions over the type of the lambda. This can work out really well if you pay attention to how function inlining happens, as the compiler can not only inline the template function, but the lambda as well. You can generally assume that the compiler is capable of fully inlining maps and folds. Lastly, if your lambda doesn't close over anything, you can cast it as a C-style function pointer.

51 points by bluehex 12y ago

Talk one is here: https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ https://news.ycombinator.com/item?id=8342697 https://news.ycombinator.com/item?id=8342697

archagon 12y ago

Kind of a tangent: Mainly on Jonathan Blow's account, I've been watching a number of similar talks by low-level programmers — for example, Mike Acton's "Data Oriented Design"[1] — and following others on Twitter. I've noticed that much of the time in these presentations, there seems to be a level of disdain towards programmers who don't optimize things down to the bit. (For example, Acton follows a dozen slides on minute cache optimization — featuring assembly examples — with "Bad programming is easy" and "Design patterns are spoonfed material for brainless programmers incapable of independent thought...") This really bothers me. On the one hand, people like Blow and Acton are working on some of the most complicated software in the world, so I have to give them all my respect. At the same time, this programming style is so alien to me that I simply can't make sense of Acton's patterns and optimizations from a cursory glance. (Blow's examples from AAA development similarly disturb me, though they're much more comprehensible.) This is not what got me into programming, and yet these presentations by coders I respect make me feel like I'm a dummy who's completely "doing it wrong". I get the feeling that there's a whole separate world of these low-level, performance-optimizing developers who've shrugged off the mainstream and have their own, parallel outlook on how programming should be done. Much of the time, their ideas are very interesting to me. But I don't know how to reconcile their methodology with mine, which works on a much higher level and makes iteration and development so fun and easy — even if things like OO and design patterns bite me in the butt sometimes. I know that many of us here, spoiled by web and app development, must feel the same way. Is this sort of ascetic, hardware-savvy code really what "good programming" looks like? Because I want to get better at my craft, but it just looks like a whole lot of pain. [1]: http://www.slideshare.net/cellperformance/data-oriented-design-and-c http://www.slideshare.net/cellperformance/data-oriented-desi... Off-tangent, I am enjoying these lectures from an academic point of view, even though I don't think I would have a use for this hypothetical language!

ps4fanboy 12y ago
Agree with you, however if you watch blows talks he is very clear that he says a lot of these problems are very specific to games. And its games that really benefit from these low level optimizations.
jamii 12y ago
I really enjoy reading the Bitsquid blog (two guys who made a game engine and sold it to autodesk). They have a much more balanced take on the subject (eg http://bitsquid.blogspot.com/2011/12/pragmatic-approach-to-performance.html http://bitsquid.blogspot.com/2011/12/pragmatic-approach-to-p...) and lots of practical examples (eg http://bitsquid.blogspot.com/2012/09/a-data-oriented-data-driven-system-for.html http://bitsquid.blogspot.com/2012/09/a-data-oriented-data-dr... , http://bitsquid.blogspot.com/2014/08/building-data-oriented-entity-system.html http://bitsquid.blogspot.com/2014/08/building-data-oriented-...). There are benefits not just to performance but to clarity and debuggability. It becomes much easier to figure out where your program is spending time or where data is being corrupted because work is done in large, homogeneous chunks instead of being spread all over the stack trace.
- NickPollard 12y ago
  The Bitsquid developers are very, very savvy programmers and I find myself agreeing with almost all the design decisions they made in their engine - in fact, my engine uses a lot of similar patterns and constructs. I wasn't aware they had sold to Autodesk though.
dkarapetyan 12y ago
Understanding the entire stack is in general a good thing but you're looking at it wrong. These guys are good programmers but they have spent decades doing this stuff so comparing yourself to them is a completely unfair comparison. Plus, like everyone else they are not objective observers and have a bias when it comes to expressing their opinions on this stuff. If all you do day in day out is optimize low level code then of course you are going to attach more value to low level optimizations and machine level understanding. Now contrast this with the likes of Alan Kay, Bob Harper, Benjamin Pierce, etc. and you notice the same pattern. These people couldn't care less about the low level details and instead espouse the benefit of high level theoretical understanding and how such knowledge advances the field. Both viewpoints are correct and balancing those two viewpoints is where the engineering aspects of software engineering come into play.

implicit 12y ago

About 23 minutes in, Mr. Blow says that lambdas has "questionable performance," but the actual cost is relatively predictable. Current C++ compilers will try to inline lambdas. Mr. Blow's specific example will be inlined by both g++ and clang, (I haven't tested MSVC) depending on the optimization level you set. std::function does introduce overhead, and the reason why is important: How can you implement an array of lambdas that all accept the same signature, but close over different kinds of environments? You need to be able to copy and destruct those environments without static knowledge of how big they are and what's in them. std::function makes this work by allocating the environment on the heap and hiding it from the type signature. If you are averse to this extra overhead, there's a really easy rule to follow: Until you actually explicitly write "std::function" in your code, you do not pay its cost. I know a few ways around this: If you always use auto when dealing with function-local lambdas, you don't pay any extra overhead. You can think of each lambda as being the sole instance of a struct that contains the environment to be closed over, plus a non-virtual method. Just be aware that no lambda is type-compatible with any other. (exception: two lambdas are type-compatible if they have empty environments and the same type signature) You can templatize lambda-consuming functions over the type of the lambda. This can work out really well if you pay attention to how function inlining happens, as the compiler can not only inline the template function, but the lambda as well. You can generally assume that the compiler is capable of fully inlining maps and folds. Lastly, if your lambda doesn't close over anything, you can cast it as a C-style function pointer.