Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
In the latest Intel-sponsored Gamasutra feature, Goo! creator Tommy Refenes' technical article tackles the serious subject of creating and managing efficient and effective multi-threaded code by comparing it to... real-life human relationships?
December 24, 2008
Author: by Staff
In the latest Intel-sponsored feature, part of the Gamasutra Visual Computing microsite, Goo! programmer Tommy Refenes tackles the serious subject of creating and managing efficient and effective multi-threaded relationships. In his own inimitably amusing fashion, Refenes compares the benefits and challenges of multi-threading relationships to real-life relationships: "Good relationships are wonderful; bad relationships make you question everything about yourself and cause your world to crumble. When you first meet someone, everything is new and shiny and wonderful, and it seems as if the sky is the limit for your happiness. Well, it's the same thing with threading. When you first hear about this sexy little thing called "multi-threaded programming" your mind starts racing. 'Oh, I can thread this,' you think. 'Oh, I can do this on another thread' or 'Oh, I can speed this up over two threads.' The sky's the limit, right? In a way, yes it is, but how do you know which code will benefit from threading, and which code won't? Fortunately there are signs, just as in a human relationship, that will tell you, 'She's good; stay with her,' or, alternatively, 'HOLY CRAP, GET OUT NOW!' One warning sign that programmers should look out for is when the code seems "too needy," or when it's so involved with the application that other work cannot take place during the threaded work. One warning sign is code that is too needy; that is, the code is so involved with the application that other work cannot take place during the threaded work. As an example, Refenes describes a simple game that requires several thousand objects to be updated before being rendered. "Now, there are ways you can thread this to your advantage (a multi-threaded renderer is one way; distributing the work between a number of threads is another), but if you work on just threading those object updates, your main thread will sit there and wait for the updates to finish before sending the commands to the renderer to draw the scene. This is an inefficient and a pretty useless threading application. It's like going out with your friends, while your significant other sits at home staring at the wall waiting for you to return. If you can do other work on the main thread and do not want to or can not split the work between the main thread and the object update thread, structure the work you do on the main thread such that it takes the same amount of time, or more, than the work that is run on the update thread. Otherwise, your main thread will be sitting there needlessly waiting for your update threads to finish. When it comes to threading, idle hands are the devil's playground." You can now read the full feature, which includes more entertaining analogies between multi-threading relationships and real-life relationships, as well as sample code.
Read more about:
2008You May Also Like