views:

96

answers:

6

say I have the following code:

char[5][5] array;

for(int i =0; i < 5; ++i)
{
   for(int j = 0; j < 5; ++i)
   { 
       array[i][j] = //random char;
   }
}

Would there be a benefit for initializing each row in this array in a separate thread?

Imagine instead of a 5 by 5 array, we have a 10 by 10? n x n?

Also, this is done once, during application startup.

+1  A: 

On modern hardware? Probably none, since you're not doing any significant computation. You'll most likely be limited by your memory bandwidth.

Pretty easy to test though. Whip up some OpenMP and give it a whirl!

genpfault
+1  A: 

Doubtful, but for some point of n x n, maybe... but I'd imagine it's a really high n and you'd have probably already be multi-threading on processing this data. Remember that these threads will be writing back to the same area which may also lead to cache contention.

If you want to know for sure, try it and profile.

Stephen
+1  A: 

Also, this is done once, during application startup.

For this kind of thing, the cost of allocating the threads is probably greater than what you save by using them. Especially if you only need to do it once.

Justin Ardini
+3  A: 

You're joking, right?

If not: The answer is certainly no!!!

You'd incur a lot of overhead for putting together enough synchronization to dispatch the work via a message queue, plus knowing all the threads had finished their rows and the arrays were ready. That would far outstrip the time it takes one CPU core to fill 25 bytes with a known value. So for almost any simple initialization like this you do not want to use threads.

Also bear in mind that threads provide concurrency but not speedup on a single core machine. If you have an operation which has to be completed synchronously--like an array initialization--then you'll only get value by adding a # of threads up to the # of CPU cores available. In theory.

So if you're on a multi-core system and if what you were putting in each cell took a long time to calculate... then sure, it may be worth exploiting some kind of parallelism. So I like genpfault's suggestion: write it multithreaded for a multi-core system and time it as an educational exercise just to get a feel for when the crossover of benefit happens...

Hostile Fork
As an afterthought... if you have a curiosity about "filling memory really fast", you might want to read up on the related subject of Memory-Mapped Files: http://en.wikipedia.org/wiki/Memory-mapped_file
Hostile Fork
It sounds like a stupid question for small values. A better worded question would be, is there a value of "n" for an n x n array, that makes threading more efficient.Also you answered a question I didn't necessarily ask, but wanted to know the answer to: does threading give you more performance on a single core CPU over a non-threaded calculation.
Alan
On a single CPU system threading will always be slower. But for the sake of curiosity you might pick a system configuration and try to find N. But bear in mind that there are *tons* of variables. The OS isn't obligated to schedule your threads on distinct CPUs even if it could choose to do so. There are even user options these days about prioritization of foreground vs. background processes! Threads are fundamentally about concurrency and independent tasks, you accept the performance benefit when it comes but cases like this are not good fits.
Hostile Fork
Case in point about the variables involved: I use a lot of virtual machines. My host is a dual-processor system, but the virtual machines all simulate single processor x86. Inside those VMs threads offer no performance boost.
Hostile Fork
Interesting that you mentioned VM's. When running a protein folding client, I noticed a boost when running the client on my machine, as well as two VM's on the same machine (anything more, or less would reduce total hours). Which is why I was curious, because it's not what I would expect. The application was locked to a single instance, which is probably the real bottle neck.
Alan
Meaning, that on modern processors (at least with Hyper threading support) would see an advantage a la Divide and Conquer.
Alan
+2  A: 

Unless you're doing a significant amount of computation, no, there will not be any benefit. It's possible you might even see worse performance due to caching effects.

This type of initialization is memory-bound, not CPU bound. The time it takes to initialize the array depends on the speed of your memory; your CPU will just waste cycles spinning waiting for the memory operations to commit. Adding more threads will still have them all waiting for memory, and if they're all fighting over the same cache lines, the performance will be worse because now the caches of the separate CPUs have to synchronize with each other to avoid cache incoherency.

Adam Rosenfield
+1  A: 

I did something similar, but in my case, the 2d array represented pixels on the screen. I was doing pretty expensive stuff, colour lerping, Perlin noise calculation... When launching it all in a single thread, I got around 40 fps, but when I added slave threads responsible for calculating rows of pixels, I managed to double that result. So yes, there might be situations where multithreading helps in speeding up whatever you do in the array, providing that what you do is expensive enough to justify using multiple threads.

You can download a live demo where you adjust the number of threads to watch the fps counter change: http://umbrarumregnum.110mb.com/download/mnd (the multithreading test is the "Noise Demo 3").

mingos
The win here is from multi-threading the non-trivial calculations, not simple array accesses.
Donnie
Yes, that's exactly what I meant to say: it can be faster if the calculations are expensive enough. Oh, and that's only when you have 2+ CPU cores :).
mingos