Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2]

Author Topic: Simpler alternative to multithreading (maybe)  (Read 3423 times)

Draco18s

  • Bay Watcher
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #15 on: April 27, 2012, 04:20:32 pm »

So what does the main instance do while it's waiting for the pathfinding to complete?  Just... sit there?  Go on to something else?

What main instance?  That's not how multithreading works.

Which instance runs this code?

Code: [Select]
for each creature that needs pathfinding
    spawn pathfinding(creature)
sync

If you have a non-null answer that is your main thread.  If you have a null answer, how the hell did the threads get spawned?  If you have multiple answers, repeat the question for those answers (i.e. what spawned them).

(i.e. stop being stupid: there's always a "main" instance, especially for a program that parallelizes only portions of its code as you are suggesting)
Logged

thisisjimmy

  • Bay Watcher
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #16 on: April 28, 2012, 06:52:53 pm »

So what does the main instance do while it's waiting for the pathfinding to complete?  Just... sit there?  Go on to something else?

What main instance?  That's not how multithreading works.

Which instance runs this code?

Jeoshua's question doesn't make sense because there's no "main instance" that needs to do stuff while the pathfinding tasks execute.  There's no CPU core sitting idle.  I'm not suggesting that there's no original thread that spawns the others.  You're misinterpreting my post.
Logged

Jeoshua

  • Bay Watcher
  • God help me, I think I may be addicted to modding.
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #17 on: April 28, 2012, 09:42:41 pm »

Jimmy, what I was point out was that there is one "thread" which is spawning the other threads.  Call it "main()" since the game is coded in C/C++ (I think).

What does that instance do while the pathfinding occurs?  Wait for the other threads?  Go on to something else?  My statement makes complete and total sense to anyone who understands programming in the slightest.
Logged
I like fortresses because they are still underground.

Draco18s

  • Bay Watcher
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #18 on: April 28, 2012, 09:55:47 pm »

Jimmy, what I was point out was that there is one "thread" which is spawning the other threads.  Call it "main()" since the game is coded in C/C++ (I think).

What does that instance do while the pathfinding occurs?  Wait for the other threads?  Go on to something else?  My statement makes complete and total sense to anyone who understands programming in the slightest.

This. :|

there's no "main instance" that needs to do stuff

There's always a main instance.  There's always a main class, which contains a main constructor, that is the MAIN thread of execution.  It doesn't have to be called "main" (depending on the language) but often is (in C++ there actually is required to be a function called "main" which serves this purpose).
« Last Edit: April 28, 2012, 09:58:14 pm by Draco18s »
Logged

thisisjimmy

  • Bay Watcher
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #19 on: April 28, 2012, 11:06:26 pm »

Jimmy, what I was point out was that there is one "thread" which is spawning the other threads.  Call it "main()" since the game is coded in C/C++ (I think).

What does that instance do while the pathfinding occurs?  Wait for the other threads?  Go on to something else?  My statement makes complete and total sense to anyone who understands programming in the slightest.

My pseudocode is borrowing terminology from Cilk.  Read what the spawn and sync keywords mean at http://en.wikipedia.org/wiki/Cilk, and you should understand the answer to your question.  If not, reply here and I'll try to explain more clearly.

Jimmy, what I was point out was that there is one "thread" which is spawning the other threads.  Call it "main()" since the game is coded in C/C++ (I think).

What does that instance do while the pathfinding occurs?  Wait for the other threads?  Go on to something else?  My statement makes complete and total sense to anyone who understands programming in the slightest.

This. :|

there's no "main instance" that needs to do stuff

There's always a main instance.  There's always a main class, which contains a main constructor, that is the MAIN thread of execution.  It doesn't have to be called "main" (depending on the language) but often is (in C++ there actually is required to be a function called "main" which serves this purpose).

Why are you quoting me out of context?  I said this:
Quote
Jeoshua's question doesn't make sense because there's no "main instance" that needs to do stuff while the pathfinding tasks execute.  There's no CPU core sitting idle.  I'm not suggesting that there's no original thread that spawns the others.  You're misinterpreting my post.

I'm not denying that there's a main thread.  Also, the term "instance" is not a synonym for thread.

There's always a main class, which contains a main constructor
This is simply false.  A C++ program isn't required to have any classes or constructors.  There's only a main() function.
Logged

Jeoshua

  • Bay Watcher
  • God help me, I think I may be addicted to modding.
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #20 on: April 29, 2012, 11:39:12 am »

Once again masterfully avoiding the point with anger and finger pointing.

The answer, in case you missed it, is that if you used Clik++ for this, that the program would STILL WAIT for the pathfinding to be finished.
Logged
I like fortresses because they are still underground.

Draco18s

  • Bay Watcher
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #21 on: April 29, 2012, 11:43:06 am »

Once again masterfully avoiding the point with anger and finger pointing.

The answer, in case you missed it, is that if you used Clik++ for this, that the program would STILL WAIT for the pathfinding to be finished.

Zing.
Logged

thisisjimmy

  • Bay Watcher
    • View Profile
Re: Simpler alternative to multithreading (maybe)
« Reply #22 on: April 29, 2012, 12:30:29 pm »

Once again masterfully avoiding the point with anger and finger pointing.

The answer, in case you missed it, is that if you used Clik++ for this, that the program would STILL WAIT for the pathfinding to be finished.

I'm not angry and I'm not pointing fingers at anyone.  I just thought wikipedia could explain better than I could.

How it works is each pathfinding task gets added to the thread pool with the spawn keyword.  When the main thread hits the sync keyword, it stops and waits as you said.  This frees up that core to do one of the pathfinding tasks.  No cores sit idle.  If you have 4 cores, it will run pathfinding for 4 creatures at a time (provided at least 4 creatures need pathfinding).  This can, at best, make pathfinding run up to 4 times faster (although the speedup would probably be less in practice).
Logged
Re: Simpler alternative to multithreading (maybe)
« Reply #23 on: April 29, 2012, 12:41:34 pm »

How about implementing such a system in the way that Animal Crossing does?

AC is a bit like a rogue-like in how it forces you to save before turning it off, and you may only have 1 town on your memory card. However, you can interact (visit) other towns on other memory cards, even sending/receiving mail to/from them and, in the sequels, move your own house and cataloged items to the new town.

Instead of syncing them together while they both run simultaneously, one save can read the available information from another saved game (IE a current game exited by saving the game and not abandoned forts/retired adventurers) and allow for remote manipulation of the 1st save file from within the 2nd.

Though neither this nor your original suggestion seem to have anything to do with multithreading... Running two instances of a program that is single threaded (whether or not they are linked) is not the same thing as multithreading 1 instance of the program. They would both still run on one CPU core, and now since you're running two of them, they are taking up twice as much power on 1 core.
« Last Edit: April 29, 2012, 12:45:19 pm by TheCoolSideofthePIllow »
Logged
Pages: 1 [2]