Threading is great! but is it great for physics?

BlitzMax Forums/BlitzMax Programming/Threading is great! but is it great for physics?

Nate the Great(Posted 2009) [#1]
Hi

I have been working on a verlet physics engine and I was wondering if it is a good idea to incorperate threading into the physics engine or is it even possible for that matter? I think I can get it set up so that there are 2 threads.. one would be the game. the second one would update the physics. Sorry I am new to threading so please share your thoughts on using threading like this. One last question. Is this what threading was meant for? if not then what was it meant for?


Htbaa(Posted 2009) [#2]
I've never done anything with threads yet so I've got no experience on that field. But having read quite a few things about it I think updating the physics is something that belongs to the main game loop.

Stuff I'd want to be using threads for is stuff like AI. Like in an RTS where for every AI commander a thread is being used to plan strategies, command units and such. Or a path finding algorithm when using very big maps, which normally could give the game hick ups because it's taking a bit too long before a path has been found.


Just some thoughts.


Edit: Just found this page (http://farseerphysics.codeplex.com/Thread/View.aspx?ThreadId=27737). They are talking about having a thread which updates the physics at a higher frequency than the amount of frames that are being rendered. So you'll get a thread for running game logic, and a thread for rendering.


Nate the Great(Posted 2009) [#3]
Hmm.. I see your point. Maybe everything that could be slow but the physics should be done in a thread?


ImaginaryHuman(Posted 2009) [#4]
If it's possible there could be some benefit to even breaking up your physics into several threads, especially if you're doing a lot of it, so that people with multi-core CPU's can benefit from extra performance. I guess the main thing is you try to shovel off the main bottlenecks of the application - the cpu intensive parts - into an additional thread, or more than one, to take advantage of cpu cores. I don't really feel that it helps a whole lot in terms of using threads to just make an application more object-oriented. Why bother unless you plan to really have the other thread running in parallel - and how can it really do that if you don't have multiple CPU cores? The o/s will multitask for you but it's virtual.

I would think you'd want at least one physics thread, then maybe a thread for ai, one for script execution, maybe one for other logic, one for streaming files from disk, one for graphics, etc.


Htbaa(Posted 2009) [#5]
Unless it's stuff that depends on data from the other threads I guess. Because when thread 1 needs data from thread 2, but thread 2 locks that data then thread 1 still has to wait.


Armitage 1982(Posted 2009) [#6]
I'm using Box2D Brucey Mod in a medium size project.
All I can tell you by using the threaded version of BlitzMax is that I get periodic tiny Freezing each second probably due to the new Garbage Collector a bit slower.
But since thread is not a needed feature for this project I will probably stick with a normal build mode.
Think about it ;)


Retimer(Posted 2009) [#7]
If it's possible there could be some benefit to even breaking up your physics into several threads, especially if you're doing a lot of it, so that people with multi-core CPU's can benefit from extra performance.

It would be great if you can impliment physics with several threads without issue, but I can see a large range of challenges with using threads for physics. One of the main issues I assume is real with that, is that with delta timing, or fixed rate logic, threads are going to cause some strange results with physics. One goofed thread would do a lot of bad.
I think I can get it set up so that there are 2 threads.. one would be the game. the second one would update the physics.

I see no reason why that wouldn't work, and it would be a fairly simple task compared to spreading out the same job with numerous threads. Start small until we all find out just what blitzmax' threads are capable of ;)
All I can tell you by using the threaded version of BlitzMax is that I get periodic tiny Freezing each second probably due to the new Garbage Collector a bit slower

My users reported this a while ago as well, back during SVN. Using the collector less frequently seemed to help a lot, as I haven't heard any complaints since. Hopefully it can be improved over time though.


Nate the Great(Posted 2009) [#8]
Thanks for the advice. I planned it out and studied threads a little more and I think its going to work out, but for now its only experimental. no guarantees about a threaded physics engine. :P


Armitage 1982(Posted 2009) [#9]
My users reported this a while ago as well, back during SVN. Using the collector less frequently seemed to help a lot, as I haven't heard any complaints since. Hopefully it can be improved over time though.


Very interesting features :)
Do you know where I can find informations on setuping GC ?
Thanks


Space_guy(Posted 2009) [#10]
Well you just have to set the GC to manual and then your self use gccollect at the interval you specify. It doesnt make the problem go away though and i experemented alot with it. Even tried to put the garbage collection in a seperate thread ;) BUt nothing compares to using the old GC. It just wont get that smooth with the new one.


Retimer(Posted 2009) [#11]
It doesnt make the problem go away though and i experemented alot with it


You're right it doesn't fix the issue, but having it less frequently makes it almost an invisible issue. When you're running collect over and over in a loop you'll see your app just rip your resources to hell over time, but having it every lengthened interval, you probobly wont even catch the spike in the task manager. That's what i've found in my case anyways.

no guarantees about a threaded physics engine. :P


When will it be released? <grin>


lukehedman(Posted 2009) [#12]
I've been rebuilding my program framework to make it naturally threaded. I figure, even with the current threading problems it's best to jump right in. Threading is only going to become more important in the future. Of course, I'm only working on personal projects right now. If I were selling games, making things smooth would be much more important.

Sometimes I think Mark has a reputation for releasing updates rather slowly, but I trust him work out the issues with the new features over time, so I'm not worried (much, that is) about the new garbage collector.



As far as physics and threading goes, I've been doing some experiments. My current project is divided into several zones/levels/areas/etc, so even if physics can't be split among threads, each zone can still have a thread of its own. The smaller zones are, the more useful this becomes.

I agree that even if physics can't thread much, there are still some pretty awesome uses. I'd imagine AI will become much easier, especially since AI has always been a big focus of mine. Motion planning is going to be so much easier!

And yeah, drawing and physics can be separate. Just that makes threads more worthwhile. Plus multiplayer (mostly TCP sockets) will become more powerful.



If I discover a good use for threading, I'll try and let the people here know. I'm pretty much a newbie though, so don't expect anything great.


ImaginaryHuman(Posted 2009) [#13]
Would be nice if the new garbage collector were not so greedy - maybe Mark can recode it a bit so that it only collects a specified percentage of objects each time you call GCCollect() and rotates through which batch it does, so that you can make the updates smoother?


MGE(Posted 2009) [#14]
I wouldn't use threads for any Blitzmax game. Especially if you're targeting casual gamers. Only optimize if you have to. Only use threads if you have to.


Dreamora(Posted 2009) [#15]
Fully agree with MGE.

Threads are great when the environment allows them to play out.
But don't force them in just to have them in, especially if you have little experience with them, as you basically can lose a lot of performance.

Have seen that happen more than once even with AAA class products, that the performance basically degraded on real multicore systems when multithreading was introduced.

The only things where I really see good use for threading is networking, stream IO and likely the very most important one: handling of user inputs in a GUI application to ensure that it always remains responsive. (in the past the by far largest drawback of BM)


ziggy(Posted 2009) [#16]
I don't agree with Dreamora or MGE, I understand their point, but given that the logic of a program has to be speficially designed to be thread-safe when working with threaded code, I think it is not a good idea to design an application in single thread mode, and 'optimize' for multithreading later, if needed. "Optimizing" for multi-thread in a safe way usually means a complete rewrite. Also the garbage collector works in a diffent way, so your code has to reuse as many objects as possible and, if it is a game, I'm sure you'll need to use a smoth delta-timing mechanism to prevent small lock-ups when the garbage collector is running, so all in all, has to be coded from the starting for multi-thread operation.

Now answering your question, yes, multithreading is great for physics calculations. Depending on how you are designing your code you can paralelize the physics calculations with other areas of the game or even split the physics calculation into several threads and sync it to the regular single thread logic.


Dreamora(Posted 2009) [#17]
And in which way do you now actually disagree?
Thats basically what has been said.
It can be great if utilized right and be the dead end otherwise.

The common user here is not even able to develop a physics system, completely ruling out a threaded physics system and naturally the required implementations of performant multithread data structures which do not exist in BM unlike .NET / Java, but which are required to pass data in and out of the physics system in an efficient way


ziggy(Posted 2009) [#18]
@Dreamora: I was refering exactly to this:
I wouldn't use threads for any Blitzmax game. Especially if you're targeting casual gamers. Only optimize if you have to. Only use threads if you have to.

It's obvious you only have to optimize when needed, but threading is not something you can plan in a later stage, you better decide it on the design stage. That's the only point, and I think you're right in what you say. It's just that I don't see like a good idea to encourage people to introduce threads as a sort of 'you want to improve performance here, use threads.' and that's what, especially the MGE post, look like to me.
that's all!


Dreamora(Posted 2009) [#19]
Ah ok
Yes fully agree


Grover(Posted 2009) [#20]
Hrm. Seems alot of people here are mixing multi-threading with multi-processing ALOT. They are NOT the same. A multi-core does NOT automagically make good use of a multi-threaded application. A core in a multi-core machine has assigned resources, and in fact multi-threaded apps most often SLOW DOWN processing on multi-core cpus because of the horrible cache thrashing, and context switching it incurs. Your best bet, to make use of multi-core (multi processors - remember each core usually has up to 4 threading units internally) is to make multiple processes that communicate through IPC or similar. This is where you can gain huge performance benefits.

Put simply, when running a thread from a single Blitz Process, you are basically asking the cores to swap out their mem access, and processing pipes - this is a _huge_ stall and thus why you see no great perf benefits.

For physics you can do some neato tricks by running a 'physics world' side by side your 'game world', and synchronize intermittently. X360 & PS3 games do this quite commonly these days. However you need to make a physics process that manages itself, and a communication system (can do it in many ways even network!! :) ) that talks between the processes. In our simulators we found IPC is the easiest to setup and use, but theres a number of ways to do it.

Threads these days are somewhat debatable for use in performance apps (like games) due to the overheads that can be incurred just by the OS swapping threads in/out of the pipes. A rule of thumb I generally go by is if you need more threads than you can run on your CPU (on one core) then there is probably something design wise wrong and worth revisiting why threads have been chosen in the first place - launch another process, you will benefit far more.


MGE(Posted 2009) [#21]
Actually...mine was a typo. I meant to say "only use threads if you WANT to." ;)