by Jim Dempsey
In the previous post we looked at using the QuickThread toolkit to write a two-stage input pipeline to boost the performance of the input side of your application. Today we look at using the QuickThread toolkit to write a high-performance output end of an application. QuickThread is available from QuickThread Programming.

Recap summary from Two-Stage Input Parallel Pipeline: Part 1
a) Read-in option data consisting of 10,000,000 options in ASCII text format and convert into internal data structures
b) pass option data through the Black-Scholes function computing strike price and saving it in an output array.
c) Convert the 10,000,000 price information results back to text and write to output file.

On a Dell R610 with 2x Intel Xeon 5570 processors, with one iteration for step b), we have as time in seconds:
Serial: a) 33.361, b) 0.859, c) 8.394, total 42.614
OpenMP: a) 33.636, b) 0.107, c) 8.439, total 42.181
TBB: a) 33.402, b) 0.108, c) 9.317, total 42.826
Win32 Threads: a) 41.888, b) 0.089, c) 8.421, total 41.888
QuickThread: a) 4.393, b) 0.088, c) 1.565, total 6.047

In the first article we showed how to obtain a 7.8x improvement in the input phase of the program. Today we will look at how to attain a 7x improvement in the output phase of the program.
First, we will digress a little by asking and answering a rhetorical question:
Why isn’t a 3-stage parallel pipeline used?

The answer is: In a real application, you may very well structure the program to use a 3-stage parallel pipeline. However, for the requirements of this benchmark, the center stage b) is required to iterate multiple times when run under the guise of the original benchmark which is used to measure the computation efficiency within region b). Due to the runtime of region b) being relatively short, many iterations are required (typically 100) to obtain a more accurate measure of performance.

Full Story