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?
Current uses for threads
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Current uses for threads
Last edited by Lap on Sun Oct 09, 2011 3:05 am, edited 1 time in total.
Re: Current Uses for Threads
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
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
Last edited by kraftman on Sun Oct 09, 2011 3:16 am, edited 1 time in total.
- Taehl
- Dreaming in associative arrays
- Posts: 1025
- Joined: Mon Jan 11, 2010 5:07 am
- Location: CA, USA
- Contact:
Re: Current Uses for Threads
Yeah... I guess threads would be very handy for listenservers, but aside from that, I know what you mean about the data divide.
Earliest Love2D supporter who can't Love anymore. Let me disable pixel shaders if I don't use them, dammit!
Lenovo Thinkpad X60 Tablet, built like a tank. But not fancy enough for Love2D 0.10.0+.
Lenovo Thinkpad X60 Tablet, built like a tank. But not fancy enough for Love2D 0.10.0+.
Re: Current uses for threads
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).
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
![Mad :x](./images/smilies/ms-mad.png)
[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).
I wonder if there's any way to use threads to improve LUBE.Taehl wrote:I guess threads would be very handy for listenservers,
- slime
- Solid Snayke
- Posts: 3156
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: Current uses for threads
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
EDIT: yeah. Don't create 1,000 threads, that's not how it works. :p
Last edited by slime on Sun Oct 09, 2011 4:31 am, edited 1 time in total.
Re: Current uses for threads
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... everLap 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 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
- TechnoCat
- Inner party member
- Posts: 1611
- Joined: Thu Jul 30, 2009 12:31 am
- Location: Milwaukee, WI
- Contact:
Re: Current uses for threads
You're getting killed by overhead. Try a reasonable number like 8 threads.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.
- josefnpat
- Inner party member
- Posts: 955
- Joined: Wed Oct 05, 2011 1:36 am
- Location: your basement
- Contact:
Re: Current uses for 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.
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.
Missing Sentinel Software | Twitter
FORCIBLY IGNORED.
<leafo> when in doubt delete all of your code
<bartbes> git rm -r *
<bartbes> git commit -m "Fixed all bugs"
<bartbes> git push
FORCIBLY IGNORED.
<leafo> when in doubt delete all of your code
<bartbes> git rm -r *
<bartbes> git commit -m "Fixed all bugs"
<bartbes> git push
Re: Current uses for threads
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.
- bartbes
- Sex machine
- Posts: 4946
- Joined: Fri Aug 29, 2008 10:35 am
- Location: The Netherlands
- Contact:
Re: Current uses for threads
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.
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.
Who is online
Users browsing this forum: Bing [Bot] and 5 guests