Multi-threading

About multi-threading i heard you guys talk about it and said it gets confusing with multi-threading, but with processors today the rewards are much greater than the work.

I’m planning to implement multi-threading (among the other plans I have) in my animation code. It just needs a bit of a refactor, then I can create a simple single-threaded path and create a multi-threaded one later when I have the time.



Most talk I’ve seen seems to be about putting animation, physics and AI into separate threads, as splitting up the rendering loop wouldn’t work. I’ve no idea how easy it’d be to run the physics on a separate thread, and currently there’s no AI package for jME.

i don’t think there should be a AI package really what use is it?

AI is one of those features which are never concrete and I doubt you can really abstract it all that much.

Better off concentrating on other features.



Back to MT.



You need to synchronise things like collisions with graphics and data.

Imagine hitting a tennis ball and it moves 3 seconds later, things like that would result if synchronisation isn't perfect.

It takes a lot of work to synchronise objects in threads, but the end result might be worthwhile, and in future may yield some benefits.

K.I.L.E.R said:

You need to synchronise things like collisions with graphics and data.
Imagine hitting a tennis ball and it moves 3 seconds later, things like that would result if synchronisation isn't perfect.
It takes a lot of work to synchronise objects in threads, but the end result might be worthwhile, and in future may yield some benefits.


I don't think that would be a good use of threading anyway.

I don't really think you should do unintelligent multi-threading.  I mean if you add it, have one thread that does the main normal game stuff, and then, lets say you are running 30 fps, then what you might want to do is if the time it took to render the current frame took less than 1/30th of a second, pause the current thread, spawn a new thread that can do things that require no input from the environment (user, other players etc.), then once 1/30th of a second is over pause the current thread and start the previous one again.  I just don't think that having 60 threads is going to help out a lot the system could potentially go into a deadlock and also we can't assume that all cpu's can do multi threading as well.

Actually multithreading would help in several situations IMO.



One example:

Assume you have a game where you control a character (or car or w/e) in a big virtual world. You may want to split this world into regions and load that on demand. As soon as you're near a border so that the adjacent scene will become visible a separate thread could load your scene while the player can still control his character. This was not working in 0.8 and I have to check for 0.9 when I find some time. The problem was that the loading thread needs access to the DisplaySystem and that could not be done in two threads.

That's why you pull all the tasks that have to create any wait-state out of the update method.  This is the same deal as with AWT/Swing guys.  You have a single-threaded UI that needs to remain single-threaded.  However, that doesn't mean you can't start your own worker threads or more explicit types of threads specific to your game.



I don't really think this is something jME really needs to worry about at this juncture though as it's something specific to the implementer.  I have suggested the idea of a dynamic loader/unloader for large scenes that may have too much to load at one time into memory and that would be its own thread, but once I have something more concrete we'll see if it's worth sticking into jME.



There are specific reasons the graphics thread is and should remain single threaded.  If you develop your applications correctly this is not a down-side at all.  In fact, it can provide you with many advantages.



darkfrog

The "loading while playing" scenario should be possible now - renanse fixed the mentioned issue that prevented that.

Well would it help for each game type method to have it's own thread like rendering,init,clean up another thing that could happen is we put  stuff like physics,AI,and effects into another thread.  If there are more than one thread I think JME should check and take advantage of it plus it can't really hurt proformance.  Only problem Ii see coming of that is people who don't have a HT processor or dual core and we set JME up run stuff in sync. Anyway even if it's not a proformance gain it'd help it in some way what doesn't kill it makes it stronger.

(i'm really getting active on the forums hope you guys don't mind)

Well your statement of having a thread for rendering, init, cleanup, etc. is a bad thing because init must come before rendering and cleanup must come at the very end.  The same problems exist when dealing with physics, AI, etc. because these things are tied to each other and expect a synchronization.  For example, you need the physics to be synchronized with the graphics because otherwise you could have visualizations that don’t correspond with the physics occuring.  Obviously this is a bad thing.  A single-threading model is there for a reason and although in certain circumstances multithreaded applications can seriously increase performance as a basic building block of jME (or any graphics engine for that matter) it just doesn’t really make a lot of sense.



That being said, there are definitely aspects of a game need to be separated into their own thread.  For example any work that would take more than a millisecond to be done should really exist outside of the graphics thread so you don’t get serious graphics lag (such is the problem you’ll often find in Swing in regards to an application trying to execute a task in the graphical thread so the refresh gets blocked until it has completed which causes a blank screen often times).  A good example of this is a networking API (http://odenetworking.dev.java.net).  It makes sense that the networking aspect of your application exist in its own thread and then make reference calls to your graphical and/or physics objects as necessary which would then be updated in the graphics thread.



Just because multi-threading CAN be faster doesn’t always mean it IS faster. :)  It has its place, but synchronization and order of events is generally the biggest concern with taking a single-threaded model and making it multi-threaded.



darkfrog

:smiley: i didn't mean for rendering,init,clean up to be done in that order but yes that would be bad if it was like that

still wondering a few thing you said synchronization of threads along with order of events is the biggest concern I thought that there was a java method to have the threads run in sync but I have not done to much work in multi-threading but what I have gathered from my own logic even is thatthreads might be started and end at the same time it doesn't mean they are in synchronization right? 



And how exactly is order of events a concern i program follows the flow of code (this happends, then this, finally this) I'm not seeing how that'd be a problem if synchronization is done right.



All of a sudden i feel like going into JME's core and finding out the effects of multi-threading

Well, if you synchronize two threads you lose all benefits of a multi-threaded system and at that point you've got to ask yourself why in the world you have two threads when you're doing the work of one…



The main purpose of threads is so that two (or more) blocks of code can run independently of each and one of those threads can continue to execute code while the other thread is working on something else.  The same purpose for having multiple processes running on the machine on an application specific level really.  Threading is one of those things that can be WAY overdone and WAY underdone.  I think this is one of those places where it would be overkill trying to add multithreading capabilities where it really just has no purpose.  Nearly everything in jME needs to be synchronized at all times, so other than loading things, question dialogs, etc. it just doesn't make sense.  Those things may or may not need to be multi-threaded, but that's up to the coder to deign necessary.



You are more than welcome to monkey around (hehe) with the source code and try to make multithreading work.  My words are just cautionary though as thus far only discussion time has been wasted discussing this, I am just trying to keep you from wasting a lot of your time on something that need not be done.  However, that's my opinion though and I'm often wrong, so I'll leave you with that. :slight_smile:



darkfrog

I still don't get why running 2 threads synchronized would be bad they still would be independent blocks of data running.  What effect do you think the little thing below would have on proformance:



current:

main–>system init–>game init–>render–>update(repeat render/update as fast as possible intill interuption)–>then reinit or clean up when called



My proposal

main–system init


>render---render(intill interupted then goes to clean up or reInit)
          game init-->update---->update

while system init is getting it's stuff together game init gets geometry and such ready and then the crazy begins by having 2 threads doing render/update  we would doubling the fps!  but i'm still skeptical it's so easy

major synchronizing would have to be done but if done right it would double the fps

I should edit my last post but i'm starting to think it wouldn't work like i planned because it'd still be waiting on render like it is now only thing i can think of is have 2 completly diffent things that share info and overwrites each other giving it a faster response rate but slightly faster render.  Isn't there like a list of stuff to be rendered that i could split up into 2 things kinda like SLI and Crossfire then 1 thread updates and they both render half of all that has to be rendered.  that would increase fps alot

example:

main–>system Init—>game Init(1/2)–>render(1/2)-|          /|–render(1/2)

                                                                          update                      repeat intill interupted            (same idea as SLI divide the work)

                          —>game init(2/2)–>render(2/2)-|/          |–render(2/2)

::edit::

kind of like xith3d render atoms i belive the developers never felt it nessasary or they stopped working on it about the time it was released

hehe, wake, you are missing one major issue here.



Multiple threads does not make anything inherently faster.  You said it would double the FPS…that's absolutely not true.  It's not like we're adding a second processor that completely handles another thread.  Multi-Threading (just as is Multi-Processing) is really a facade.  We can gain benefits from it as programmers but the speed gain is by intelligent design (wow, first time I've used that term in a programming context) in so much that we can share time between two blocks of code.



Multi-Threading (and Multi-Processing) shares the same CPU, so they really do not work individually, they are forced to "share".  Each thread gets some CPU time and then is expected to pass back control so that another thread can use some CPU time.  More than one thread inherently make the other thread go slower, but in specific situations there is performance gained when there is a wait-state on the other thread, not because it adds speed, but more CPU time is allotted to it because the other thread isn't using as much.  Problems occur when one thread doesn't want to work and play well with others.  This is what Thread.yield() and Thread.sleep(int) are for.  They will allow control to be taken away from them and passed off to other threads in the multi-threaded architecture (or even other processes) and then when those threads or processes pass back control it will eventually end up back at the thread that yielded or slept (that is, if the threads are good little threads).



I would highly encourage you to read a tutorial about threads as it seems you don't really understand exactly what their purpose is.  I don't think there is any way that multi-threading jME as far as updates and rendering would add any performance boost whatsoever.  I think it would be problematic and purposeless.



Dividing work is exactly what threading is about, but at the same time the idea behind update and render is that they minimize the amount "work" being done and that they are constantly in-sync.



Anyone smarter than I willing to comment on this as well is more than welcome.  I could be wrong, and as I'm still relatively new to 3d game writing I very well could be, but most of this perspective is derived from my professional career as a Java developer.



darkfrog

darkfrog said:

hehe, wake, you are missing one major issue here.

Multiple threads does not make anything inherently faster.  You said it would double the FPS....that's absolutely not true.  It's not like we're adding a second processor that completely handles another thread. 

But I am, I am talking about processors able to handle multiple threads it's becomming more common everyday.  Intel has HyperThreading,The new IBM G5 chips can handle 2 threads(3 are used in xbox 360 thats 6 threads going at once!)the playstation 3 will have 6 threads.  There are dual core chips coming out and if you like intel and have $1,000 you can get 4 threads. 

Um, remember there is only one bus to the graphics memory - so accessing the card with two threads (or even two cores) is rarely gaining any performance speedup. Additionally it causes problems (or even does not work) with the GL.



And probably check out some articles on multithreading, as synchronizing threads often can result in even worse performance than with a single thread.



As a result it makes sense to separate only that things into different threads that do not (or do rarely) access the same resources (e.g. different memory; or graphics vs. entities).

Thanks Irrisor, I just don't think he believed it coming from me. :o



darkfrog

alrite I give in to your wisdom guess i wanted to belive something else