Quick and dirty multithreading?

From Visual Basic to GNU C, this is the place to talk programming.

Moderators: SecretSquirrel, just brew it!

Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 2:07 am

I was wondering. If I created four single threaded console based C or C++ programs and set each one's affinity to a certain core in my system, that would keep my four cores fully utilized, right? To minimize I/O latencies, I could use a ram drive, seeing how cheap ram has become ( I have 32GB DDR3-1600 lying around coz I didnt get time to assemble my new system). I could use the same ram drive to store files that would serve to act as a sort of communication medium between the four processes.

This might not be the most efficient way to do multithreading but at least it would save me from having to learn all about semaphores and mutexes and locks and what not. I have nothing against learning but considering the limited time I have these days, this crude way seems to be the quickest way for me to concoct something that might give me some cheap thrills for a little while (OH WOW LOOK! MY PROGGIES ARE USING ALL FOUR CORES! :D ) Any thoughts on this, guys?
Igor_Kavinski
Gerbil XP
 
Posts: 322
Joined: Fri Dec 22, 2006 2:34 am

Re: Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 3:28 am

Well it's not multithreading, you're just using multiple processes. Not that anything is wrong with that though! Personally, I wouldn't bother with setting affinity, as the OS scheduler can do its job just fine.

If your type of processing can easily be done in parallel with multiple processes, and getting the quickest turnaround time is less important than overal throughput, I'd say go ahead and do it this way. If you have a large number of jobs to be processed, I'd add another process to do simple queuing and dispatching, to keep all cores busy at all times.
Firestarter
Gerbil XP
 
Posts: 485
Joined: Sun Apr 25, 2004 11:12 am

Re: Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 9:31 am

Igor_Kavinski wrote:I was wondering. If I created four single threaded console based C or C++ programs and set each one's affinity to a certain core in my system, that would keep my four cores fully utilized, right? To minimize I/O latencies, I could use a ram drive, seeing how cheap ram has become ( I have 32GB DDR3-1600 lying around coz I didnt get time to assemble my new system). I could use the same ram drive to store files that would serve to act as a sort of communication medium between the four processes.

This might not be the most efficient way to do multithreading but at least it would save me from having to learn all about semaphores and mutexes and locks and what not. I have nothing against learning but considering the limited time I have these days, this crude way seems to be the quickest way for me to concoct something that might give me some cheap thrills for a little while (OH WOW LOOK! MY PROGGIES ARE USING ALL FOUR CORES! :D ) Any thoughts on this, guys?



Well what you're doing is just ignoring those multithreading objects. If you want to ignore them/not use them you are free to not use them in a single process with multiple threads, too. At least then you'll be able to let the threads access the same memory addresses way easier, too.

just use the __BeginThread function from win32.
GACKT ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Dual nehalem Xeon e5520 / 16 GB DDR3 / GTX 280
mph_Ragnarok
Graphmaster Gerbil
 
Posts: 1315
Joined: Thu Aug 25, 2005 7:04 pm

Re: Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 10:44 am

This might be a very dumb question but I thought the return of time investment on multithreaded programming isnt all that great unless your problem is easily parallelizable. So why go that route? Why not just concentrate on increasing the single threaded utilization of all the cores by dividing your workload into manageable single thread processes?

I mean, one has to wonder that if instead of a single EXE, game developers created a number of different ones each designed for a different job (GPU rendering, physics, AI, sound etc) and used interprocess communication to synchronize them so they work in tandem to achieve a common goal. What are the drawbacks of that compared to multithreaded programming?
Igor_Kavinski
Gerbil XP
 
Posts: 322
Joined: Fri Dec 22, 2006 2:34 am

Re: Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 10:52 am

Igor_Kavinski wrote:This might be a very dumb question but I thought the return of time investment on multithreaded programming isnt all that great unless your problem is easily parallelizable. So why go that route? Why not just concentrate on increasing the single threaded utilization of all the cores by dividing your workload into manageable single thread processes?

I mean, one has to wonder that if instead of a single EXE, game developers created a number of different ones each designed for a different job (GPU rendering, physics, AI, sound etc) and used interprocess communication to synchronize them so they work in tandem to achieve a common goal. What are the drawbacks of that compared to multithreaded programming?



Conceptually there is no difference between using multi-process and multi-threading. In real terms with multi-threading you have the threads sharing the same address space and usually what you think of as the same "program". You can program your algorithms the same way for both methods...
multi-threading just gives you the additional flexibility to let the threads cooperate faster . but of course there is no requirement that the threads communicate or share data at all.

so my point is why make a messy multi-process application that where processes don't share data or work when you can just use a simple BeginThread calls from a single process that spawns several threads? the CPU cores get the same work done.
GACKT ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Dual nehalem Xeon e5520 / 16 GB DDR3 / GTX 280
mph_Ragnarok
Graphmaster Gerbil
 
Posts: 1315
Joined: Thu Aug 25, 2005 7:04 pm

Re: Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 11:53 am

I want more control because the Windows thread scheduler seems to bounce around threads for no reason. If I make it multithreaded, then I am at the mercy of whatever crazy algorithms have been programmed into the scheduler.
Igor_Kavinski
Gerbil XP
 
Posts: 322
Joined: Fri Dec 22, 2006 2:34 am

Re: Quick and dirty multithreading?

Postposted on Fri Jun 22, 2012 2:14 pm

Igor_Kavinski wrote:I want more control because the Windows thread scheduler seems to bounce around threads for no reason. If I make it multithreaded, then I am at the mercy of whatever crazy algorithms have been programmed into the scheduler.


Yea that is true :/ Though I'm never sure keeping a process pinned to a single core is better anyway. It's not like the the caches and registers in a CPU aren't cleared out when other processes running on the computer get their turn at a core.
GACKT ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Dual nehalem Xeon e5520 / 16 GB DDR3 / GTX 280
mph_Ragnarok
Graphmaster Gerbil
 
Posts: 1315
Joined: Thu Aug 25, 2005 7:04 pm

Re: Quick and dirty multithreading?

Postposted on Sat Jun 23, 2012 11:51 am

Your IPC overhead will likely eat up any benefits of binding to a specific processor on Windows. If you are accessing the same files from different processes you still need to synchronise file access between the processes. Synchronisation objects aren't that hard to understand once you get a handle on them once.
notfred
Grand Gerbil Poohbah
 
Posts: 3736
Joined: Tue Aug 10, 2004 10:10 am
Location: Ottawa, Canada

Re: Quick and dirty multithreading?

Postposted on Sat Jun 23, 2012 2:15 pm

notfred wrote:Your IPC overhead will likely eat up any benefits of binding to a specific processor on Windows. If you are accessing the same files from different processes you still need to synchronise file access between the processes. Synchronisation objects aren't that hard to understand once you get a handle on them once.


Yea seriously, it's not hard at all. It's all very intuitive. And the Win32 sync objects are all really simple to use, too, just check msdn for some few specifications and that's all you need :)
GACKT ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
Dual nehalem Xeon e5520 / 16 GB DDR3 / GTX 280
mph_Ragnarok
Graphmaster Gerbil
 
Posts: 1315
Joined: Thu Aug 25, 2005 7:04 pm

Re: Quick and dirty multithreading?

Postposted on Sat Jun 23, 2012 4:32 pm

#pragma omp parallel for and compile your C/C++ program with -fopenmp on a modern compiler.

Place that #pragma directly above any for() loop and the compiler will automatically optimize the loop to use all possible cores. This is a starting point. Look up OpenMP for more. Its incredibly simple and easy to use.
eternalmatt
Gerbil
 
Posts: 22
Joined: Tue Aug 14, 2007 11:56 am

Re: Quick and dirty multithreading?

Postposted on Mon Jun 25, 2012 5:25 pm

1. What you're proposing isn't multithreading in the usual sense. But if the task being performed by each process is truly independent of the others (i.e. no sharing back-and-forth of intermediate results), then there's probably no compelling reason to do "true" multithreading, and what you propose may in fact be a good solution.

2. Except in very specialized cases, there is no need to worry about thread affinity. Unless you've conducted performance tests on your application which demonstrate that throughput is consistently being hurt by the lack of thread affinity, you really want to just let the OS scheduler do its thing.
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 37737
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Quick and dirty multithreading?

Postposted on Mon Jun 25, 2012 7:58 pm

I put multi-threading into my game because I wanted the UI to be responsive while stuff goes on in the background. So for example, I put the music and sound effects in their own threads.

Turning a self-contained piece of code into a thread is extremely easy, I think you should at least try it?

I dont think multiple processes vs multiple threads would change whether you need to worry about semaphores and mutexes.
ShadowTiger
Gerbil First Class
Gold subscriber
 
 
Posts: 124
Joined: Wed Oct 01, 2008 2:39 pm

Re: Quick and dirty multithreading?

Postposted on Wed Jul 18, 2012 7:07 pm

eternalmatt wrote:#pragma omp parallel for and compile your C/C++ program with -fopenmp on a modern compiler.

Place that #pragma directly above any for() loop and the compiler will automatically optimize the loop to use all possible cores. This is a starting point. Look up OpenMP for more. Its incredibly simple and easy to use.


It does make it easy to run code in a multi-threaded and load-balanced way, but it does not handle any resource sharing or scalability issues of the code in the loop.
bcronce
Gerbil
 
Posts: 18
Joined: Tue Jun 03, 2008 5:12 pm

Re: Quick and dirty multithreading?

Postposted on Wed Jul 18, 2012 7:17 pm

Igor_Kavinski wrote:I want more control because the Windows thread scheduler seems to bounce around threads for no reason. If I make it multithreaded, then I am at the mercy of whatever crazy algorithms have been programmed into the scheduler.


I believe Windows round robins the thread across the cores as an element of power management/heat reduction.
"Welcome back my friends to the show that never ends. We're so glad you could attend. Come inside! Come inside!"
Ryu Connor
Global Moderator
Gold subscriber
 
 
Posts: 3547
Joined: Thu Dec 27, 2001 7:00 pm
Location: Marietta, GA

Re: Quick and dirty multithreading?

Postposted on Wed Jul 18, 2012 9:02 pm

Ryu Connor wrote:
Igor_Kavinski wrote:I want more control because the Windows thread scheduler seems to bounce around threads for no reason. If I make it multithreaded, then I am at the mercy of whatever crazy algorithms have been programmed into the scheduler.


I believe Windows round robins the thread across the cores as an element of power management/heat reduction.


The pre-Win7 thread scheduler looks for the lowest core to run a thread that is coming out of sleep. This means when you have one active thread, it will constantly round-robin the cores as the current core will always be the heavily loaded.

eg. An active thread is running on Core 0. This means Core 0 is at 100%. When that thread's time-slice is up, the OS almost immediately reschedules that thread because it's the only one active. When the scheduler looks at which core to run on, it sees Core 0 is at 100%, so it schedules the thread on Core 1. Rinse and repeat.

Win7 tries it's best to not move a thread unless it has to, and it will also shut-down other cores that are not in use. Win7 will not wake-up a slept core until the current cores reach some-threshold, which I think is 110% load. This sacrifices a small amount of throughput for a large potential in power-savings.
bcronce
Gerbil
 
Posts: 18
Joined: Tue Jun 03, 2008 5:12 pm


Return to Developer's Den

Who is online

Users browsing this forum: No registered users and 2 guests