7 replies to this topic

[rouncer]

Im just about to speed up an algorythm which takes a few seconds to
get through by splitting it up into threads for my dual core, and hopefully
quad core when I get my next computer.

Id like to hear if anyone has done this and got any success from it, what
it was, how you did it, and how much performance you got from it, because
it would help me out a bit.

Thanks for anyone willing to share anything.

[Reedbeta]

It depends very much on the problem and algorithm. Some algorithms are very easy to parallelize, others are very hard. What is the problem you are trying to solve?

[TheNut]

The most common gaming related parallelism comes from running a physics simulation in one thread and the renderer in another. I've tried it but noticed no speed improvement. Then again, you need a crazy nice looking game for this sort of application to have any use.

[rouncer]

Reedbeta said:

It depends very much on the problem and algorithm. Some algorithms are very easy to parallelize, others are very hard. What is the problem you are trying to solve?

Im taking a 3d poly object, and converting it to a voxel model by using a 3d triangle raster comparing it to a 256x256x256 array so i dont repeat voxels.

Its taking about 6 seconds to do a 256 cubed sphere.

The Nut- thats a damn shame, I hope I get some improvements. Otherwise
whats the point in buying a dual core if its not much benefit anyway...

[Reedbeta]

That could probably be sped up rather easily by taking splitting the volume into n pieces (where n is the number of cores you have) and rasterizing each piece in a separate thread.

[rouncer]

Have you coded anything in parrallel personally?

[Wernaeh]

Quote

I've tried it but noticed no speed improvement. Then again, you need a crazy nice looking game for this sort of application to have any use.

Actually, that's not entirely true. You won't get much of a speed improvement if you are running at maximal FPS even on a single core already.

However, there are some other advantages in going multithread:

- Logics and rendering frame rate become independent.

This allows for quite high a logics rate (such as 100 logics frames a second), coupled with a much lower rendering frame rate (30 frames per second). This might just be a personal feeling, but the game seems to respond more fluidly if the logics framerate is that high.

- Logics doesn't break in when rendering does.

There might be small in-between peaks in rendering (such as looking around in a terrain) and your rendering time will fluctuate rapidly. This actually causes much more visible "lag" than just a low FPS. In a single-threaded design, this lag also grows into your game logics, which adds to the unfluid feeling and may give problems with other timing-critical code, such as networking. Multithreading however, takes some of this problem off by distributing time among your threads.

(Note you could simulate both by just storing all rendering commands, and processing a certain number of these after each logic frame, but it's more complicated than multithreading, and you don't use that second / ... / core of your computer -- just running a rendering frame every n logic frames does give a little hickup if rendering takes too long)

- Loading screens are so much nicer to add when your rendering system is already multithreaded. Just pass control of the renderer to an extra thread (loading thread), which then can do some sort of animation while your main program thread parses game data.


However, I'm not sure if that is worth the extra code and extra design needed for implementing a threaded solution - after all, it's more difficult to ensure the correctness of a multithreaded application versus the correctness of a singlethreaded one.


For a simpler problem (and a basically parallel one!) such as the 3D rasterization problem provided by the original poster, threading definately is the way to go.

Cheers,
- Wernaeh

[rouncer]

Thats really interesting that you brought that up W, I never thought of
that.
So splitting your logic from your render on different cpus makes a lot
of stuff easier to do.
I definitely might implement it next time im writing a game.