Ferrous Moon
http://www.ferrousmoon.com:80/forums/

Multithreading
http://www.ferrousmoon.com:80/forums/viewtopic.php?f=9&t=812
Page 1 of 1

Author:  Burningmace [Wed Jul 18, 2007 5:31 am ]
Post subject:  Multithreading

As of current I don't know of any section of the code that is multithreaded. To improve game performance on multiprocessor (incl. multicore) systems, the music playing code should be executed in its own thread. This will also have a benefit on uniprocessor systems, as cpu time scheduling can be managed much more effectively when threads are used. The reason I say the music engine is that it doesn't really require much interaction with anything else - it can be spawned, left to do its thing and finally aborted when the user exits the game.

I'm not sure how multithreading works in C++ as regards code, but in C# it works something like this:
Code:
using System.Threading; class myApp { Thread t = new Thread(new ThreadStart(this.musicThread)); musicEngine m = new musicEngine(); public static int Main(string[] args) { m.Init(5,3); t.Start(); return 0; } public static void EndGame() { // Called when the exit button is pressed // Do cleanup t.Abort(); // End } } class musicEngine { int someVar = 0; public void EngineLoop() { // This MUST NOT write to any variables outside this method unless they are thread-safe! // i.e someVar may be read, and writing probably won't be a problem. // An attempt to write to a windows forms control will cause an exception. try { do while(1) { // Process the music /* - Music Code Goes Here! - */ Thread.Sleep(0); // Yeild the remainder of the CPU time block to other operations. Thread.SpinWait(1); // Prevent LoaderLockException by synchronising across threads. } } catch (System.Threading.ThreadAbortException) { // The thread has been aborted. The game is probably in shutdown. // Cleanup code can go here, but is probably not needed. // This exception pulls execution out of the code loop. } } public void Init(int varA, int varB) { someVar = varA * varB; // Initialise some variables } public void New() { } }
Now don't take that to be 100% correct, I'm a VB.NET man myself. Obviously this is in a .NET language, so it'll need translating across to C++. However, if implemented correctly, putting music in its own thread would probably improve game performance by a reasonable amount.

Author:  Darkknight512 [Wed Jul 18, 2007 8:04 am ]
Post subject: 

It already runs fast enough

Author:  Burningmace [Wed Jul 18, 2007 8:19 am ]
Post subject: 

It's still worth doing. If you listen carefully to the music, it glitches out every so often during hacks or when the world map is up with a large bounce route. Multithreading will help reduce this. On top of that, it really doesn't run fast enough. It lags a bit on my machine with a large bounce route up, and I'm running dual 8800 GTX 768MB cards and an Intel Core 2 Duo E6600, with 2GB of DDR2 PC2-8888. It will even reduce the amount of CPU usage for the game, because the threads can yeild execution to other processes much more often than a single threaded application can.

Author:  frenchfrog [Wed Jul 18, 2007 8:23 am ]
Post subject:  Re: Multithreading

Quote:
As of current I don't know of any section of the code that is multithreaded.
IRC mod is multithreaded with a producer/consumer model (At least in the Uplink codebase ;) ).

Author:  Burningmace [Wed Jul 18, 2007 8:33 am ]
Post subject: 

Of course it is. You can't have a single threaded IRC system, because you couldn't do asynchronous messaging events if it were single threaded. Well, you sort of could, but it'd be really hard and would hog performance like a bitch. I should have clarified what I meant when I said that. I don't know any part of the engine code that is multithreaded, for additional performance reasons.

Author:  Darkknight512 [Wed Jul 18, 2007 1:51 pm ]
Post subject: 

I tested to see if the bouncing will slow down the and/or glitch the music, I bounced to all the systems I could find at internic and the music was fine, I run a pentium M 1.5 ghz with 512 mb of ram and 64 mb of Vram.

Author:  prophile [Wed Jul 18, 2007 4:14 pm ]
Post subject: 

Threading isn't simple in C++.

Author:  FinalWarrior [Wed Jul 18, 2007 4:44 pm ]
Post subject: 

I get slowdown on the connection map as well. It's only graphical, though, but I can tell; when you have a bunch of connections running and you mouse-over one of the buttons, the text that dsiplays comes out at a crawl.

I'm running an AMD64 FX-57 and a single 7800GTX.

-- Griffinhart

Author:  Darkknight512 [Wed Jul 18, 2007 4:46 pm ]
Post subject: 

I got no problems what so ever. Even my crappy 64 mb Intel extreme graphics 2

Author:  Tycho [Wed Jul 18, 2007 8:53 pm ]
Post subject: 

Multithreading hasn't been a concern yet for Onlink, really. I did consider it seriously, but instead decided to tackle algorithm optimization (Tosser data structures). With those data structures greatly enhanced for speed, the rest is mainly graphics slowdown caused by using immediate mode rendering. Our current bottleneck isn't the CPU, it's the GPU.

I may yet do multithreading for enhanced speed, once we deal with graphics speed (prophile will tackle the immediate mode issue, very likely). Is anyone here familiar with OpenMP? It can greatly improve speed via multithreading without adding much complexity to the code (Onlink would need a rewrite from scratch to implement multithreading if OpenMP didn't exist).

Multithreading is the future of programming, since we keep seeing more cores on one processor die than ever before. Clock speed will increase, but very little. Intel decided to stop pushing clock speed and instead push core speed (drop trace cache, add code cache, enhance instruction decoding, shifts, rotates, and general execution speed). So performance there will have some mobility, and without heat dissipation issues. We'll eventually have 8 and 16-core processors, which means we'll be able to run 8 threads at once and have them execute in true parallel.

Right now, Onlink uses one thread, sure. Is it a problem? Yes. Will we add multithreading? I can experiment with it, see what performance increases we get. We'll deal with OpenGL first, though. Once that's resolved, we'll more seriously consider multithreading.

Oh, and Burningmace: C#'s multithreading is nothing like C++. C# is something akin to Java (what a shock, considering its roots. hah.), so it's all ridiculously object-oriented and almost every UI action is threaded. C++'s threading varies from platform to platform, at the moment. OpenMP resolves this, but until GCC 4.2.0 is mainstream (put out by each distro), Linux multithreading will be through pthreads, and Mac multithreading through pthread/NSThread.

Author:  Burningmace [Thu Jul 19, 2007 5:26 am ]
Post subject: 

Just a note on those people getting performance drops - It's probably resolution based. If you're playing the game at 1024x768, it's not likely to lag much. However, when you're at 1920x1200, immediate mode rendering takes its toll, even on a rediculously top end system.

Author:  prophile [Thu Jul 19, 2007 2:27 pm ]
Post subject: 

Luckily, that's not going to be a problem for much longer... <cryptic>

Author:  Burningmace [Fri Jul 20, 2007 8:28 am ]
Post subject: 

Immediate mode getting pwned? :)

Author:  Tycho [Fri Jul 20, 2007 1:07 pm ]
Post subject: 

Quote:
Immediate mode getting pwned? :)
Well, it -was-. Ran into some problems. We're hoping to have 0.1.1 final out next week, but not sure with our current situation. Immediate mode replacements may have to be fixed after 0.1.1.

Author:  Miah [Fri Jul 20, 2007 5:17 pm ]
Post subject: 

That, and I'm trying to make a patch generator for future versions, and I keep running into crap that to generate a patch would require the near regeneration of the entire world...

So I'm trying to quash those things.

Page 1 of 1 All times are UTC-05:00
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/