Bearcat

In the previous article about multi-threading, I mentioned that there are 2 options for breaking up the work that needs to be done. Option 1 was to have each thread work on a subset of the portfolio, but do all the experiments. Option 2 was to have each thread work on a subset of the experiments, and to work on all of the portfolio.

Today, we'll look at option 2, and I'll try to explain what was needed in the program to accomplish this task. Option 1 and option 2 programs will look similar on the surface, but will differ in the details. We still need to think about how our data is arranged and how we can access the data, without incurring any performance penalty, by restricting access to the data. Remember again, It's all about the data. (I can't stress that enough).

So let's begin:

The "main" function stays the same. The "create_portfolio_threads" function is changed to accomplish the goal. In option 1, I created arrays for each of the threads, because each thread operated on all the experiments which are housed in the arrays. In option 2, each thread will operate on a subset of the experiments, and a subset of the array, so I only need 1 set of arrays again. I added an item "thexperiments" to the thread structure to allow the threads to calculate the area of the array to work on.

The next set of changes were made to the "portfolio" function, in which the area of the array to work on is based on the number of experiments, and the number of threads that will be used. Also I needed to change the average calculations to be based on the area of the array that was used, instead of the number of experiments.

The last change was to the "blackscholes" function, to which I now pass the start and number of the indexes of the array to be worked on, instead of the number of experiments.

That's it, not too hard, was it?

Here is the code:

MultiThread2.zip

Let's run it and see how it does:

[leo@compute70 MultiThread2]$ time ./mthread2
=== Option Portfolio Calculations (Threading over number of Experiments Test) ==========
Portfolio size : 1024
Experiments run per item : 1000000
Number of threads started : 4
Thread 0, Running Experiments 1 to 250000 for 1024 options.
Thread 1, Running Experiments 250001 to 500000 for 1024 options.
Thread 2, Running Experiments 500001 to 750000 for 1024 options.
Thread 3, Running Experiments 750001 to 1000000 for 1024 options.
Thread 0, Average Call Price : 36.561064
Thread 0, Average Put Price : 1.669508
Thread 3, Average Call Price : 36.829648
Thread 3, Average Put Price : 2.142390
Thread 1, Average Call Price : 36.854430
Thread 1, Average Put Price : 2.156009
Thread 2, Average Call Price : 36.809930
Thread 2, Average Put Price : 2.150635

real 4m50.480s
user 19m3.825s
sys 0m0.077s
[leo@compute70 MultiThread2]$


There you go, 4 minutes and 50 seconds. This is about the same length of time that option 1 took to execute. So what does that tell us?

It means, that this sample (and only this sample) has a certain number of calculations to do, and depending on how I slice up the work, each thread has a certain number of calculations to do, so all things being equal, if I slice up the calculations 4 ways, regardless of how I slice it up, it will take a specific amount of time to perform the calculations. So I have 1,000,000 * 1024 calculations to perform. I can slice it up by option 1 as 1,000,000 * 256 * 4, or option 2 as 250,000 * 1024 * 4, but the end result is the same.

Each option may have an advantage to a particular program, depending on the program you want to make multi-threaded, and how the data is arranged, so it's nice to have a couple of options, knowing the end result is the same, from a performance standpoint.

So, can we make this program any faster? Well, maybe, if we can run more threads, say 8, if we had hardware that big. Or, we could try to make the calculations run faster, if we had faster hardware, or maybe alternative hardware.

I'll explore these additional methods in future articles.

Multi-threading has been around for a long time, still not that well understood, I think, based on programs I've seen. Next I'll look at a newer piece of technology, that is supposed to make multi-threading easier, although I don't find multi-threading that hard to begin with. OpenMP, is technology that allows you to thread tasks within your program, to make use of multi-threading. I'll take a look at the implications of using OpenMP in this program, and see how it performs.

See you next time.

Leo Stutzmann