tag:blogger.com,1999:blog-6950833531562942289.post5211812905103427620..comments2024-03-25T03:36:48.099-07:00Comments on C0DE517E: Does it scale? Game threading laws part twoDEADC0DEhttp://www.blogger.com/profile/01477408942876127202noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6950833531562942289.post-49829675305793533492009-04-29T21:35:00.000-07:002009-04-29T21:35:00.000-07:00Well in practice is not hard. I've just finished a...Well in practice is not hard. I've just finished a game that is one of most multicore friendly game we have across all our studios. And it wasn't hard at all.<br /><br />Threading is hard. It's incredibly complicated, more than most people think. Luckily nothing of that matters for us. Even if tomorrow someone comes and makes STM perfect, with no overhead, and lets us have one actor per class, all with no overhead, it won't really matter much.<br /><br />You can thread everything and run slower than ever, where do I have time even only to fetch the code to execute, if I'm always jumping around? It's not a problem of locking or not, it's a problem of memory... We're not writing server applications, we're not IO bound, there is nothing that matters more than that...<br /><br />Luckily, we have plenty of data to process. We spawn a very few threads, two are the important ones, game and rendering. The communicate via a buffer and you can call it an immutable data structure, if you want (well that's a little bit unfair, immutable data structures are like that but with a sort of copy on write, neat stuff, but hardly relevant). We have a threadpool, a lot of data with some dependencies, and that's it... Of course we can do more, it's really a matter of rethinking a lot of processes in a more stream friendly way, but it's not a huge deal.<br /><br />Again, there are some "advanced" techniques that are fancy and can be useful, fibers can be useful to further mask latency, if your data access pattern in a given computational kernel is not so linear, agents can be nice for some types of games, but that's not the main point...DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-74512980123105547752009-04-29T09:16:00.000-07:002009-04-29T09:16:00.000-07:00"Everything else is not only complicated, but it d...<I>"Everything else is not only complicated, but it does not work at all!"</I>, yeah right on, anything which uses any type of global memory allocation can be dropped into that bucket. The scale of this logic gets scary given that a majority of programs use some type of global memory allocation...<br /><br />One other thing which should be added is that job ordering becomes highly important when going massively parallel in order to factor out fine grain locking (or collisions in atomic operations) into coarse job scheduling.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-72252262904739769492009-04-29T06:12:00.000-07:002009-04-29T06:12:00.000-07:00http://book.realworldhaskell.org/read/software-tra...http://book.realworldhaskell.org/read/software-transactional-memory.htmlAnonymousnoreply@blogger.com