Multidimensional Array Initialization: Any benefit from Threading?

Question

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? nxn?

Also, this is done once, during application startup.

Answer 1

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

Answer 2

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.

Answer 3

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!

Answer 4

Doubtful, but for some point of nxn , 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.

Answer 5

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.

Answer 6

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