LÖVE

I spent the better part of a day just tooling around with threads. I really want to see some good uses for this, but every implementation I try is just not worth doing. The biggest problem seems to be that anything complicated enough to need its own thread needs so much supporting data that the serialization and transfer of said data ends up making the speed comparable to a single thread.

Unfortunately, I haven't seen an improvement with using threads to load images and such either. Besides TLPath, I haven't seen anything that uses threads with any real benefits.

Are there any other good examples I'm missing?
More specifically any that would actually be useful in the average game?
Is there any way that the implementation of love.thread can be improved?

I think the threaded mandelbrot is a good example, it allows you to do a lot of calculations without it freezing everything.

What have you tried doing so far?

EDIT:

as another example, I've used separate threads to generate procedural worlds in the background while the main thread is just concerned with drawing the current part of the world

Yeah... I guess threads would be very handy for listenservers, but aside from that, I know what you mean about the data divide.

Things I've tried so far:

1. Using threaded pathfinding - Too much data needs to be serialized over. It becomes extremely hard to debug and code unless you are only using the most basic of systems. It's easier to just use coroutines that work in extra CPU time. I can see a very limited application in real time games with simple pathfinding, as in the TLPath example.

2. Using threading to help AI - Needs too much information that lies in the main namespace.

3. Quickly loading images in parallel - Does not seem to work at all. Can't separate love.draw either.

4. Improved range finding:
Throw 1000 entities on a map, calculate the closest entity within X range. Single threaded = 0.01s
Threaded method, using 1000 threads = 0.2s .

[I might post this .love file, since it also shows the difference between splitting the map into smaller grids and only checking a subset of nearby grids...still isn't that much faster in all but the biggest maps, and there's also the issue of constantly keeping the grids updated].

-------------------------

The mandelbrot one the only good example, but it has limited applications in games. Threads seem like they are only good for extremely complex calculations that require very little actual starting input (logs, fractals, pixel calculations).

Taehl wrote:I guess threads would be very handy for listenservers,

I wonder if there's any way to use threads to improve LUBE.

I am experimenting with putting update/logic/input-handling into a separate thread. I haven't got to the point where I need to serialize a ton of data though, so I'll see how that goes.

EDIT: yeah. Don't create 1,000 threads, that's not how it works. :p

Lap wrote:4. Improved range finding:
Throw 1000 entities on a map, calculate the closest entity within X range. Single threaded = 0.01s
Threaded method, using 1000 threads = 0.2s .

admittedly i really don't know anything about multithreaded programming but i don't think you're supposed to use that many threads for a game like... ever

you're probably going to want a better algorithm than check-every-object. maybe use hardoncollider's spatialhash module, then use the getNeighbors method to get all objects inside the bounding box that fits the range you need. since it's a box though you'd have to iterate through all the returned objects and perform the distance check on them

Lap wrote:4. Improved range finding:
Throw 1000 entities on a map, calculate the closest entity within X range. Single threaded = 0.01s
Threaded method, using 1000 threads = 0.2s .

You're getting killed by overhead. Try a reasonable number like 8 threads.

I was able to get a multi-threaded implementation for a http socket. The problem is that http sockets block, and that wouldn't work for the tweening I was attempting to do.

This is really good when you don't want to use a networking library (like lube) or when you're trying to pull data simply off of a server's 80, but don't want it to block.

I know, I know, 1000 was excessive. When you bring it down to like 10 though it still isn't worth doing until you get into the thousands and thousands of entities it seems.

I've actually run love.physics in a thread.
Anyway, don't think you'll be able to make an existing game threaded easily. It's more effective if you design a multithreaded system.