Quick and dirty multithreading?

[Igor_Kavinski]

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! ) Any thoughts on this, guys?

[Firestarter]

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.

[mph_Ragnarok]

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! ) 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.

[Igor_Kavinski]

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?

[mph_Ragnarok]

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.

[Igor_Kavinski]

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.

[mph_Ragnarok]

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.

[notfred]

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.

[mph_Ragnarok]

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

[eternalmatt]

#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.

[just brew it!]

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.

[ShadowTiger]

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.

[bcronce]

#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.

[Ryu Connor]

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.

[bcronce]

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.