Thanks to a bad neck, I finally have some free time. Why not spam the blog, I thought (and why not try Windows 7 on a VM, zomg it's amazing).
While searching for cool programming stuff, I found some interesting links I have to share with you. Just two for the moment! Don't be greedy.
Smoke framework, for starters. The good thing is that what I had in mind is scarily similar to what Intel done, and this makes me a happy gummybear.
Retlang, by Mike Rettig, which seems to be the answer to my concerns about thread-safe message passing.
(And "Stackless C#", by Tim Mcfarlane, which has led me to try and learn how Irony works in order to recreate a Lua CLR compiler that supports coroutines without fugly hacks - but that better be another story for another post).
While those two links lead to resources that can only inspire the mere mortals, they also made me remove my Google Code page until I completely embrace their paradigms. That's to say I wasn't exactly happy with what I'd done and I wanted a fresh start. I think by now you noticed my big problem with finishing my own projects.
Now, you might be wondering, what's this to do with the post subject? Very well. Good question.
Smoke shows an important concept: that is to share the workload among n threads. However, as usual, it is easier said than done. Sharing the workload requires a careful design, so that nothing is left to compromise and everything falls nicely in place when all computations are done.
However, one of the biggest challenges is to actually find good heuristics so that work is spread evenly across threads. You don't want to waste time counting those threaded sheeps jump past the fence. The other is to allow an immediate flow from producers to consumers.
I have a good example of the mental maze you find yourself in once you try to make sense of the above; your rendering thread is told to render something you haven't yet loaded. An animated mesh, for instance, along with its textures and animations and whatnots.
If the rendering waited idly for that asset to be loaded, we'd be back to square one. It becomes difficult to remove dependencies from systems that'd naturally rely on them. What would the pragmatic developer do? Perhaps identify each resource with an ID, and check against that to verify if the asset has been loaded. However, spamming IDs all over the place lacks of elegance, and the initial problem leads to another sub-problem; how to organize data.
There are two kinds of data I can see right now; in-memory data, and assets to be eventually loaded in some memory (they're initially stored on disk, any type of assets, from textures to ai-behaviour-definition files, the latter being just made up).
Both have a stage in which they are not utilizable, as they're to be either created or loaded. And even when you've loaded data, there's another possible step, that is going back to storage. Persistence.
All of this needs a common interface: find necessary data, load it, access it, save it again. Rinse and repeat. Add two tablespoons of sugar. Did I mention data has to be immutable? My head is hurting.
Oh, damn. Lunch time. I was about to make a nice diagram. I'll continue later. >:)
Edit: nice diagram (click to enlarge):
While searching for cool programming stuff, I found some interesting links I have to share with you. Just two for the moment! Don't be greedy.
Smoke framework, for starters. The good thing is that what I had in mind is scarily similar to what Intel done, and this makes me a happy gummybear.
Retlang, by Mike Rettig, which seems to be the answer to my concerns about thread-safe message passing.
(And "Stackless C#", by Tim Mcfarlane, which has led me to try and learn how Irony works in order to recreate a Lua CLR compiler that supports coroutines without fugly hacks - but that better be another story for another post).
While those two links lead to resources that can only inspire the mere mortals, they also made me remove my Google Code page until I completely embrace their paradigms. That's to say I wasn't exactly happy with what I'd done and I wanted a fresh start. I think by now you noticed my big problem with finishing my own projects.
Now, you might be wondering, what's this to do with the post subject? Very well. Good question.
Smoke shows an important concept: that is to share the workload among n threads. However, as usual, it is easier said than done. Sharing the workload requires a careful design, so that nothing is left to compromise and everything falls nicely in place when all computations are done.
However, one of the biggest challenges is to actually find good heuristics so that work is spread evenly across threads. You don't want to waste time counting those threaded sheeps jump past the fence. The other is to allow an immediate flow from producers to consumers.
I have a good example of the mental maze you find yourself in once you try to make sense of the above; your rendering thread is told to render something you haven't yet loaded. An animated mesh, for instance, along with its textures and animations and whatnots.
If the rendering waited idly for that asset to be loaded, we'd be back to square one. It becomes difficult to remove dependencies from systems that'd naturally rely on them. What would the pragmatic developer do? Perhaps identify each resource with an ID, and check against that to verify if the asset has been loaded. However, spamming IDs all over the place lacks of elegance, and the initial problem leads to another sub-problem; how to organize data.
There are two kinds of data I can see right now; in-memory data, and assets to be eventually loaded in some memory (they're initially stored on disk, any type of assets, from textures to ai-behaviour-definition files, the latter being just made up).
Both have a stage in which they are not utilizable, as they're to be either created or loaded. And even when you've loaded data, there's another possible step, that is going back to storage. Persistence.
All of this needs a common interface: find necessary data, load it, access it, save it again. Rinse and repeat. Add two tablespoons of sugar. Did I mention data has to be immutable? My head is hurting.
Oh, damn. Lunch time. I was about to make a nice diagram. I'll continue later. >:)
Edit: nice diagram (click to enlarge):
A Rain Song: now with nice pictures!
Why two servers with the same processing units? Our ultimate goal is to plug one more server and see performance double instantly. More or less. The same goes for three servers, and so on.
More on this later, car's getting brake pads changed and I need to take it back.
