So who here is thinking of using Grand Central Dispatch?

DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #16
There are advanced "parallel iterative" solvers for systems of equations. In fact, the iteration that Chipmunk does could as well be applied to any other system of equations, instead of "object by object", that's just an implementation detail.

You can thread many iterative solvers, even accurately, as the numbers tend to spread row and column-wise, so you only need to sync up the edges of a region, it's just that the cost of all this numeric mumbo-jumbo is often quite large, and you need very large system to see a real boost.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #17
GhostDog Wrote:I use threads for background loading of assets and streaming data. Physics certainly is a candidate but I think the sound system is even lower hanging fruit.

If you're using Core Audio, you're already threaded. There's no practical way to break it down any more than that since, unlike a game frame, the audio *must* be delivered on time or your ears will bleed. Rasp

[edit] Actually, I take that back, there *is* a way to break audio down further by vectorizing it, which has proven big wins, but that's parallelized by instruction rather than what we're talking about here with entirely separate threads.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #18
I'm about to get started on a voxel based terrain editor app, sort of like mudbox. A sculpting app. I'm planning on using blocks & gcd.

Currently I tessellate on two threads, but the code's a little ugly. I'm planning on modifying the underlying voxel data as well as tessellate using blocks & gcd. I think it will be fun.
Quote this message in a reply
Member
Posts: 35
Joined: 2009.10
Post: #19
GhostDog Wrote:I would highly recommend considering threads and laying the framework for non-synchronous operations sooner rather than later no matter what you plan to use it for. It is much harder to go back and refactor single-threaded code than it is to make the up front investment (even if it is minimal) for concurrent operations. Bite the bullet early and it will make your life a lot easier if you plan on growing a common code base to consider this feature in the beginning. Even on single cores, it's a nice way to think about parsing jobs and dividing up work for systems.

Yeah, that was why I wanted to design for concurrency early. Doing that design is proving harder than I thought. Shock

Going along with the discussion on physics, I'm probably going to use Bullet for my physics engine, or at the very least for collision detection (I kind of wish they'd finish their C API though). I believe Bullet has support for multithreading, but I'm not sure if it could work with GCD or if it has to use its own internal system.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #20
Coyote Wrote:Going along with the discussion on physics, I'm probably going to use Bullet for my physics engine, or at the very least for collision detection (I kind of wish they'd finish their C API though). I believe Bullet has support for multithreading, but I'm not sure if it could work with GCD or if it has to use its own internal system.

Bullet kicks butt IMHO. I've been toying with it on and off since June, and I'm *definitely* going to be using it for my future projects. And yes, it is totally cool that you can use just parts of it, like the collision detection. And "me too" on the "I wish they'd finish the C API" thing. So far I've been able to make simple shims in the C API to the C++ methods, although admittedly, I haven't done anything terribly complex yet. The *only* thing I can complain about is the rather spartan documentation for it (which is a pretty important missing feature!).

I wish I knew anything about its threading possibilities, but I haven't investigated yet.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #21
AnotherJake Wrote:Bullet kicks butt IMHO. I've been toying with it on and off since June, and I'm *definitely* going to be using it for my future projects. And yes, it is totally cool that you can use just parts of it, like the collision detection. And "me too" on the "I wish they'd finish the C API" thing. So far I've been able to make simple shims in the C API to the C++ methods, although admittedly, I haven't done anything terribly complex yet. The *only* thing I can complain about is the rather spartan documentation for it (which is a pretty important missing feature!).

I wish I knew anything about its threading possibilities, but I haven't investigated yet.

I've had good luck with bullet for simple collision response, but the joint and motor types have been pretty weak. Though they *are* getting better, in fact Erwin implemented some detail in linear motors simply because I asked about them on the bullet forum. Quick development!

Trouble is, the documentation is terrible. I pretty much have to have text mate open on the bullet source tree to act as docs.

So, I'm still using ODE. Someday, bullet. Someday.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #22
TomorrowPlusX Wrote:Trouble is, the documentation is terrible. I pretty much have to have text mate open on the bullet source tree to act as docs.

Heh, yeah, I'm pretty much running off of what's in the Bullet headers myself too. If I didn't have some previous knowledge and experience with other engines, forget it, I'd be completely lost.
Quote this message in a reply
Member
Posts: 35
Joined: 2009.10
Post: #23
Much of the reason I'm attracted to Bullet is because it includes continuous collision detection.

But I'm not exactly looking forward to integrating a C++ library into my C/Objective C project. Especially if I want to be able to serialize its collision shape objects into my model files.
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
Post: #24
Not to get too far off topic here, but, ya....Bullet's documentation is pretty bad.

Coyote, a word of warning: yes, they do have continuous collision detection (it was the reason I originally looked into the library, too), but it's still considered unstable, and I never could get it working. This was several versions ago, though, so it may be better now.

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2009.05
Post: #25
Coyote Wrote:Yeah, that was why I wanted to design for concurrency early. Doing that design is proving harder than I thought. Shock

Going along with the discussion on physics, I'm probably going to use Bullet for my physics engine, or at the very least for collision detection (I kind of wish they'd finish their C API though). I believe Bullet has support for multithreading, but I'm not sure if it could work with GCD or if it has to use its own internal system.

It's not easy and you are not alone. I've been in the games industry for about 10 years now and it's still an issue that we have to address on every project. Consoles had forced us into this line of thinking a ways back but now with multi-core CPUs and devices like the iPhone, it's becoming a common problem. I wish I had this resource back at college when taking my Parallel Programming class but check this stuff out. IGNORE the ai aspects...it's horrible and you never want to do your interactions like this. But pay attention to the framework and how to parse jobs. It's really a nice way to organize your systems for n-way threading of game systems. Plus you get code which is always nice.

http://software.intel.com/en-us/articles...logy-demo/
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #26
GhostDog Wrote:http://software.intel.com/en-us/articles...logy-demo/

Interesting link!

This discussion reminds me of a quote by John Carmack a while back:

“Hardware wise, there's a lot of marketing hype about the consoles. A lot of it really needs to be taken with grains of salt about exactly how powerful it is, ... The Xbox 360 has an architecture where you essentially have got three processors and they're all running the same memory pool and they're all synchronized, and cache coherent, and you can spawn off another thread in your program and make it go do some work. That's kind of the best case and it's still really difficult to turn into faster performance or getting it to get more stuff done in a game title.”
Quote this message in a reply
Apprentice
Posts: 6
Joined: 2009.05
Post: #27
Quote this message in a reply
Post Reply