<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Wed, 23 May 2012 11:08:05 -0700 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments Feed</title>
    <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By sunny0104</title>
      <description><![CDATA[ Thank you ,up ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9300</link>
      <pubDate>Thu, 27 Nov 2008 16:36:46 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9300</guid>
    </item>
    <item>
      <title>By James Munro</title>
      <description><![CDATA[ Is there any way of obtaining a PDF formatted copy of this article, or even a hard-copy? This will prove extremely useful in my dissertation, thanks! ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9307</link>
      <pubDate>Fri, 28 Nov 2008 05:15:16 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9307</guid>
    </item>
    <item>
      <title>By bgkyer</title>
      <description><![CDATA[ Great article - you should fix the link to threadingbuildingblocks.org at the end (typo in it - &#39;threadind&#39;). I honestly think this could be further genercised to a parallel application engine with just a few alterations on the base objects.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9404</link>
      <pubDate>Wed, 03 Dec 2008 11:59:20 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9404</guid>
    </item>
    <item>
      <title>By Orion Granatir (Intel)</title>
      <description><![CDATA[ Thanks for the heads up on the typo (broken link).  And we are working on getting a PDF version of the doc posted. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9444</link>
      <pubDate>Thu, 04 Dec 2008 16:55:25 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-9444</guid>
    </item>
    <item>
      <title>By James Munro</title>
      <description><![CDATA[ Thanks for uploading a PDF version, makes it easier for me to reference in university work :) ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-11522</link>
      <pubDate>Thu, 18 Dec 2008 11:45:53 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-11522</guid>
    </item>
    <item>
      <title>By Jeffrey Andrews (Intel)</title>
      <description><![CDATA[ bgkyer - you're absolutely right about this being able to be genericised for "any" parallel application.  Our goal was specifically for games since it's not necessarily simple to figure out how to get all the different systems running in parallel.  Feel free to modify the source code to suite your needs. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-11538</link>
      <pubDate>Thu, 18 Dec 2008 15:40:44 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-11538</guid>
    </item>
    <item>
      <title>By Josh</title>
      <description><![CDATA[ Hey Jeffery, Hey Orion,

Kudos to you and other members of the Smoke Technology Demo team for your great job.

There are a couple of dark areas in my mind which I'd like some light to be shed on. I'd appreciate it if you answer the following questions:

1) What are the performance characteristics of TBB's task stealing scheduler with regarding to cache coherency in the context of Game Engine Design? How did it affect Smoke's performance specifically?

2) Why do we need to instruct TBB's scheduler and arm it with pre-determined knowledge of each task's workload (as specified in PerformanceHint enumeration in TaskSchedulerTBB.cpp)? Why can't those tasks be scheduled efficiently otherwise?

3) Considering that TBB is designed for a wide range of applications, do you consider TBB's scheduler optimal (or close enough to optimal) for use in Game Engines?

4) How can I improve Smoke's scheduler / task manager? Is there any room for major algorithmic optimizations? How would you guys go about designing your own task scheduler?

Many thanks. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-12049</link>
      <pubDate>Wed, 24 Dec 2008 12:49:18 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-12049</guid>
    </item>
    <item>
      <title>By Josh</title>
      <description><![CDATA[ 5) One inherent problem that I see with Smoke's scheduler is that, if I'm not mistaken, Smoke's execution model more closely follows Bulk Synchronous Processing (BSP), although its use of a task pool can be misleading at first glance. A call to TaskManager::WaitForSystemTasks at the end of Scheduler::Execute, effectively synchronizes all tasks at the end of each frame, which is not a scalable design in that faster subsystems should now wait for slower subsystems (e.g. SystemProceduralFire) to catch up. I don't know why this came as a surprise to me since this article has explicitly stated  in section 2.1 that "execution state management works best when operations are synchronized to a clock, meaning the different systems execute synchronously." :)

Anyway, the point I'm trying to make here is that a system would be much more scalable if different subsystems can run in parallel at different frequencies. A game is mostly considered choppy when rendering is not smooth. People won't notice as much if AI or Physics run at lower frequencies. In my opinion, this reason alone is sufficient to motivate us to shift our focus to designs that promote loose coupling by allowing subsystems to run at different frequencies, of course then, the synchronization would become more of a problem.

What do you guys think? How can Smoke's design be tweaked to support this?

I'm all eyes and ears. Don't keep me waiting for too long. ;)

Many thanks in advance. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-12249</link>
      <pubDate>Thu, 25 Dec 2008 15:55:52 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-12249</guid>
    </item>
    <item>
      <title>By Orion Granatir (Intel)</title>
      <description><![CDATA[ Hey Josh,

Thanks for all the comments and feedback.
I am going to write a blog post about some of your comments so hopefully more people get their eyes on it.

Let me answer some quick questions.  I’ll try and get Brad Werth to throw in his two cents on the TBB questions.  Brad’s the individual that did most of the TBB work.  I’ll answer some of the longer questions in my blog post this week :D  I’ll post a link when it’s up.

1. TBB worked well for Smoke’s performance.  The task stealing was the real key.  I haven’t look at the performance recently.
  
If you look in Smoke.gdf, you can change the mechanism used for the scheduler: 

Change the Value from TBB to TP to use the native windows threading instead of TBB and you can compare performace.

2. & 3.  I’ll let Brad answer these.  Brad is writing an article on TBB for game engines.  TBB is an effective tool for expressing threading.  If used correctly, game engines can see a lot of benefit.  The biggest complaint I hear about TBB is the lack of PS3 support… but TBB is open source, so hopefully someone is working on a port :D

4. There is always some room for improvement.  If you look at the native windows threading (set TaskManager to TP in Smoke.gdf), you’ll see our very rough and simple task scheduler.  It’s doesn’t have all the fancy features (like tasking stealing) you get with TBB.  You hit on the number one feature I would like to add to the scheduler, free step mode (all systems don’t have a hard sync point).

5. This is the big question.  I’ll write a blog with my opinions/thoughts on this subject.  As Jeff explains in his article, this framework could run in free step mode (section 2.1.1).  There are a lot of benefits to running in free step vs lock step.  However, there are some less than obvious benefits to lock step.  We start off Smoke with at free step scheme.  But we decided to switch to lock step for simplification and time of development.  By all means, you could adapt Smoke to be free step… something I would love to see.  It’s actually not that hard (I hope)... since each system gets required data directly from the owning system, each system could buffer it’s data and update at a desired frequency.

Again, thanks for all your input.
Please keep us up-to-date on what you do with Smoke!
Thanks,
Orion
 ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13177</link>
      <pubDate>Mon, 29 Dec 2008 14:09:07 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13177</guid>
    </item>
    <item>
      <title>By Josh</title>
      <description><![CDATA[ Hey Orion,

Thanks for taking the time and writing a follow-up. I really appreciate it.

5) If we're about to stick to task pools (which by the way, being a more scalable approach to threading, is a move in the right direction IMHO) as opposed to going down the conventional route of giving each subsystem its own thread and looping at different frequencies, one way to do this is to change the tasks so they would:

a) immediately add themselves to the queue at the end of each execution
b) keep track of the elapsed time since their last execution and yield if enough time has not passed

This way, we are effectively turning that explicit loop in the one-thread-per-subsystem approach into an implicit loop. This approach is preferable if we don't want to make drastic changes to the scheduler, but puts the burden of scheduling on the tasks themselves.

A better approach that I can think of, which doesn't suit Smoke's current scheduler right out of the box, is to put this burden on the scheduler itself. This way a scheduler has an internal timer with events set at different frequencies (which we have obtained from the subsystems themselves, i.e. how many times per second does the task want to run?), each of which when fired, results in the corresponding tasks that belong to the said subsystem to execute. I haven't given this further thought though. What would happen if the system under too much pressure that can't run the tasks at the predefined intervals? Maybe a dynamic solution that alters the frequencies during the run-time would help us alleviate this problem to some degree...

But one problem remains. The downside of free step approaches in general is that it would introduce more lag into our system. In the worst case, the rendering happens before physics which takes place before AI which in turn runs before input and I'm not even taking other subsystems into considerations.

Maybe a hybrid approach is what we should be looking for.

I'd be looking forward to hearing from you.
Regards,
Josh ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13224</link>
      <pubDate>Mon, 29 Dec 2008 20:46:01 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13224</guid>
    </item>
    <item>
      <title>By Orion Granatir (Intel)</title>
      <description><![CDATA[ I wrote a quick blog about lock vs free step: http://software.intel.com/en-us/blogs/2008/12/30/lock-or-be-free/  This blog highlights some of the issues I was thinking about for question 5.

Hey Josh, you have some interesting ideas here.  I think you are right, the best place to put most of the burden would be the Scheduler.  One thing the Scheduler is lacking in Smoke is "knowledge" about running tasks.  It doesn't have priority or information for load balancing.  Right now, the Scheduler needs a large number of small tasks to keep all the worker threads busy because it doesn't try to actively load balance.  With TBB we to get some extra balancing with task stealing, but the Scheduler could to a lot more.

Thanks again for the posts and let me know what you think of the blog :)
 ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13379</link>
      <pubDate>Tue, 30 Dec 2008 16:20:02 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13379</guid>
    </item>
    <item>
      <title>By Josh</title>
      <description><![CDATA[ Hello Orion,

Informative blog post. Thanks. :)

I agree with you that lock step mode can be tweaked to better take advantage of our available resources. Lock step performs better, especially if the work is divided properly meaning that the number of available tasks (preferably far) exceeds the number of hardware threads and the jobs are relatively equal in size. I agree.

But the biggest advantage of free step execution mode is the extra flexibility it brings along. Both free step and lock step can max out our CPU usage, but free step is superior in that it's capable of delivering a better gaming experience because we can now dynamically adapt our game to the gamers' machines by allowing different subsystems to run at different frequencies. So while it's true that they both can theoretically max out our CPU usage meaning that literally no CPU cycles are wasted, but free step can partition a frame in a way that more time is devoted to those subsystems that we, as the developers, think contribute more to our game's "responsiveness".

The way I have envisioned it, we would identify our priorities in a list (i.e. 1.Rendering, 2.Physics, 3.AI and such) and when the game starts, it would scale to the gamers' machines so those subsystems that have lower priorities would slow down in favor of those that are given higher priorities. We can even let the gamer tweak this priority inside the Options menu, so for instance, if one particular gamer is more interested in a more challenging AI than more accurate physics calculations she can reverse the priorities.

Of course this is easier to say than do, but all things we have today started as ideas one day nonetheless.

I'd be looking forward to hearing from you Orion.

Kind Regards,
Josh

P.S. In case anybody comes up with other interesting ideas (or implementations!) long after this discussion is over, please don't hesitate to contact me. You can reach me at http://aphrodite3d.blogspot.com. I'm not much of a blogger as you see! ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13440</link>
      <pubDate>Tue, 30 Dec 2008 23:19:19 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-13440</guid>
    </item>
    <item>
      <title>By Brad Werth (Intel)</title>
      <description><![CDATA[ Hey, I'm responding to Josh's many insightful questions posted earlier.

1) How/Why is TBB faster for Smoke?  We didn't do a lot of deep-thinking on this -- we treated TBB as middleware and tried it out.  It has better performance, so there we go.  Conceptually the scheduler in TBB and all Cilk-style schedulers have an advantage as cores increase (no central task pool to synchronize on) and data decomposition increases (cache benefits become apparent).

2) Why do we order the tasks being submitted to TBB?  The TBB scheduler is, as an implementation detail, FIFO.  We order the tasks to put the largest indivisible work in first, so itcan get started immediately.  If it was submitted last, it would be possible for the TBB threads to start on smaller data decomposition tasks, which would increase the total frame time.

3) Is TBB appropriate for games?  Yes, we think so.  Certainly the scheduling algorithm has nice performance properties.  As with most middleware, the issue with TBB is not whether it can deliver performance (it can), but whether you can effectively utilize its organizational idiom.  I'm spending a lot of time thinking about that and how to wrap TBB better for games.  Take a look at the Pet Me demo for a simple wrapping of TBB that uses a Promises pattern (like in Java 1.5).  Pet Me is at http://www.gamasutra.com/view/feature/3876/sponsored_feature_multicore_.php.

4) How can we improve task scheduling in Smoke? As Orion wrote earlier, breaking the requirement to synchronize each frame is a natural next step.  I posted my thoughts on how to do that in Smoke as a comment to Orion's blog entry http://software.intel.com/en-us/blogs/2008/12/30/lock-or-be-free/.

5) Is it viable to have each recurring task schedule itself when finished?  It's a good idea but it's challenging to do in TBB.  The internal tree structure of TBB and the local work trees make it a challenge to put a task into the system that will be run "later".  In TBB, if a task is about to finish and makes a new child/continuation/etc to run again, that task will run next, making the effor equivalent to a while(true) loop.  You can request a specific task to run next, but how will you know what's in the task pool or which thread it is assigned to?  It's a bit of a mess.  I'm working on an article now that lays out some of these challenges and some partial solutions we've found.  I'll post a notice here when that is available.

Let me be perfectly clear that when I talk about challenges and solutions, I'm discussing the peculiarities of using TBB's API, not its ability to deliver performance.  TBB performance has been fantastic in almost every situation where we've been able to apply the library.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-14396</link>
      <pubDate>Mon, 05 Jan 2009 13:32:45 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-14396</guid>
    </item>
    <item>
      <title>By Jeffrey Andrews (Intel)</title>
      <description><![CDATA[ Hi Josh,

Thanks for giving this a really good looking over.  You've made some really good points.  I'm not working on Smoke anymore but I'm sure Orion will mull them over.

Here are some tidbits to give you a little more insight into Smoke:

. The original intent was to have the Scheduler query the system tasks on how many clock ticks they would require to execute, and ping the task if it was exceeding the requested amount.  Due to time constraints we weren't able to implement this - easy to say but hard to do.

. Free step has some extra complexities with the change notification that, again, we didn't have enough time to implement.

. Lock step can do a pseudo free step, such that, a system task that doesn't need to do anything will just return, relinquishing the thread for another task.  System tasks that need more time can break up their calculation so that they halt calculations close to when the clock tick expires and continue calculations on the next clock tick. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-14487</link>
      <pubDate>Tue, 06 Jan 2009 13:05:31 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-14487</guid>
    </item>
    <item>
      <title>By crazii</title>
      <description><![CDATA[ Hello,I'm new here,now I'm just writing something to learn the engine design stuff,especially parallelizing techs.I'm now studying and thinking carefully about your article.But I got a question that really bothers me,which is just about how to provide interface to the user,as I'm not quite experienced in such designing job.

The question is:There are many subsystems,with different functioanlities.Is it a good way that we let the client to use the system's functionality directly as using a plugin,or we need pre-define some system's interface in the framework level,for the engine? Take rendersystem as example,do we need some interface (like services) defined for it?

Hey,I don't know if it is suitable to ask it here.Anyway thank you for the article.It's awesome.
By the way,I'm using TBB for my test/study,currently it works pretty fine in Lock step mode. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-33794</link>
      <pubDate>Mon, 02 Nov 2009 01:07:58 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-33794</guid>
    </item>
    <item>
      <title>By Concurrency links &amp;laquo; StudioFortress</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-33823</link>
      <pubDate>Mon, 02 Nov 2009 13:36:47 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-33823</guid>
    </item>
    <item>
      <title>By Arni Arent</title>
      <description><![CDATA[ This architecture is flawed.

It allows different systems to submit sub-tasks into the queue, presumably for execution by an available worker thread.

This means that you can have multiple threads working on any one system. What this means is that memory that each system has is being affected by multiple threads.

That invites a lot of concurrency problems. ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-43332</link>
      <pubDate>Thu, 13 May 2010 09:44:47 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-43332</guid>
    </item>
    <item>
      <title>By Todd Seiler &amp;raquo; Concurrency &amp;amp; Parallelism</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-48321</link>
      <pubDate>Sun, 05 Sep 2010 23:08:46 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-48321</guid>
    </item>
    <item>
      <title>By Lock or Be Free &amp;#8211; Intel Software Network Blogs</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-53165</link>
      <pubDate>Wed, 08 Dec 2010 22:05:54 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-53165</guid>
    </item>
    <item>
      <title>By 关于游戏引擎多线程的一些整理和思考 | Music Sets Me Free</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-54448</link>
      <pubDate>Wed, 05 Jan 2011 05:05:53 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-54448</guid>
    </item>
    <item>
      <title>By  Concurrency &amp;amp; Parallelism &amp;raquo; Todd Seiler</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-54532</link>
      <pubDate>Thu, 06 Jan 2011 15:43:48 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-54532</guid>
    </item>
    <item>
      <title>By 
	
	
	Multi-threaded game (engine) design resources? Drija</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-59998</link>
      <pubDate>Sun, 22 May 2011 05:13:45 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-59998</guid>
    </item>
    <item>
      <title>By Resources for XNA indie developers | Indie Games Bundle - indieGamesPack.com</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-60583</link>
      <pubDate>Thu, 09 Jun 2011 10:17:54 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-60583</guid>
    </item>
    <item>
      <title>By Designing framework | Pmakit</title>
      <description><![CDATA[ n/a ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-62225</link>
      <pubDate>Sun, 24 Jul 2011 22:26:12 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-62225</guid>
    </item>
    <item>
      <title>By crazii</title>
      <description><![CDATA[ Years later now, I got a way better understanding on this.Maybe some ideas are different in details,but I get right the whole picture,and I'd say that this article is awesome! 
The TBB::task is so cool,lightweight,that's all I need for the task-manager.
the systems are almost running without any synchronization overhead.
Thanks again! ]]></description>
      <link>http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-66333</link>
      <pubDate>Sat, 05 Nov 2011 13:04:23 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/#comment-66333</guid>
    </item>
  </channel></rss>
