Kerry D. Wong » TBB

TBB Mandelbrot Set

kwong — Sun, 14 Sep 2008 02:35:48 +0000

In an earlier post, I created a simple prime finding program using Intel’s TBB (Thread Building Block). The main benefit of using TBB is that threading and thread synchronization mechanism are abstracted away within the TBB library so we do not need to deal with threads explicitly. Also, TBB is optimized for performance and scales nicely as the number of processing unit increases. In this post, I will show you how to create a Mandelbrot Set generator using TBB and how to optimize the algorithm using loop unrolling.

The standard algorithm for generating Mandelbrot Set is extremely easy to adapt to using TBB. In fact the loops look almost identical to those in the single-threaded approach, except that the iterations are calculated within a 2D range block (blocked_range2d) instead of the entire two dimensional space.

    void operator() (const blocked_range2d<size_t> &r) const
    {
        drawing_area drawing(0, 0, screen_size,screen_size);
 
        for (size_t x = r.rows().begin(); x < r.rows().end(); x++)
        {
            for (size_t y = r.cols().begin(); y < r.cols().end(); y++)
            {
                float zx = 0;
                float zy = 0;
 
                float cx = (float)x / (float)screen_size * x_range + x_min;
                float cy = (float)y / (float)screen_size * y_range + y_min;
                int i = 0;
 
                while (zx * zx + zy * zy <= 4 && i < max_iteration)
                {
                    float xtemp = zx * zx - zy * zy + cx;
                    zy = 2 * zx * zy + cy;
                    zx = xtemp;
                    i++;
                }
 
                int itr = i % 255;
                color_t c = itr << 16 | itr << 8 | itr;
 
                drawing.set_pixel(x,y,c);
            }
        }
    }

Because xlib by itself is not thread-safe, special attention must be made when trying to update the display concurrently. One way to address this issue is to employee a shared memory region (X11/extensions/XShm.h and sys/shm.h), the display is first built in memory and then the shared memory is attached to the display. In my examples above I used code (video.h, xvideo.cpp) from the sample code that come with the TBB library, which uses the shared memory method I mentioned earlier to make the X11 calls thread-safe.

Many optimization methods can be used to further enhance the performance of the algorithm. One of the most efficient methods is to utilize SSE instructions found on all modern Intel processors (examples can be found here: Using SSE3 Technology in Algorithms with Complex Arithmetic). This approach however might be difficult to implement and debug since parallel data structures must be used in order to benefit from SSE instructions. Also, explicit assembly level coding makes porting code to other machine architectures a daunting task. Modern compilers can already take full advantage of the underlying machine architecture. For example, the gcc compiler (4.2.3) already generates SSE instructions for the code snippet above. While hand tweaking using SSE instructions might further improve the performance, we would certainly sacrifice code simplicity and portability.

The approach I am going to take to further optimize the code is to use loop unrolling. Since the inner loop of the standard algorithm is pretty short, unrolling the inner loop should lessen the burden of loop overhead and decrease the chances of stalling the pipeline (when branching must be predicted). So a high-level loop unrolling should be able to improve the performance.

Here is the code after the inner loop is unrolled:

    void operator() (const blocked_range2d<size_t> &r) const
    {
        drawing_area drawing(0, 0, screen_size,screen_size);
 
        for (size_t x = r.rows().begin(); x < r.rows().end(); x+=2)
        {
            for (size_t y = r.cols().begin(); y < r.cols().end(); y++)
            {
                float zx1 = 0;
                float zx2 = 0;
                float zy1 = 0;
                float zy2 = 0;
 
                float cx1 = (float)x / (float)screen_size * x_range + x_min;
                float cx2 = (float)(x + 1) / (float)screen_size * x_range + x_min;
 
                float cy = (float)y / (float)screen_size * y_range + y_min;
 
                int i1 = 0;
                int i2 = 0;
                bool loop_stop1 = false;
                bool loop_stop2 = false;
 
                while ( !(loop_stop1 && loop_stop2))
                {
                    float xtemp1;
                    float xtemp2;
 
                    if ((zx1 * zx1 + zy1 * zy1 <= 4) && (i1 < max_iteration))
                    {
                        xtemp1 = zx1 * zx1 - zy1 * zy1 + cx1;
                        zy1 = 2 * zx1 * zy1 + cy;
                        zx1 = xtemp1;
                        i1++;
                    }
                    else
                    {
                        loop_stop1 = true;
                    }
 
                    if ((zx2 * zx2 + zy2 * zy2 <= 4) && (i2< max_iteration))
                    {
                        xtemp2 = zx2 * zx2 - zy2 * zy2 + cx2;
                        zy2 = 2 * zx2 * zy2 + cy;
                        zx2 = xtemp2;
                        i2++;
                    }
                    else
                    {
                        loop_stop2 = true;
                    }
                }
 
                int itr = 0;
 
                itr = (i1) % 255;
                color_t c = itr << 16 | itr << 8 | itr;
                drawing.set_pixel(x,y,c);
 
                itr = i2  % 255;
                c = itr << 16 | itr << 8 | itr;
                drawing.set_pixel(x+1,y,c);
            }
        }
    }

This code generates identical results as the code mentioned previously. As you can see, the inner loop is not unrolled to handle two data points at a time.

As it turned out, this algorithm runs almost twice as fast as the code mentioned earlier(280ms versus 510ms on Intel Q9450 @ 3.4GHz).

Source code for this article can be downloaded here.

A Simple TBB Program: TBB Prime

kwong — Sun, 22 Jun 2008 16:12:08 +0000

I have been playing around with Intel’s Threading Building Block for a while and have started to really appreciate its simplicity and elegance: Instead of thinking in threads and thread synchronizations, one can just simply concentrate on the problem on the hand. Take finding prime numbers for example, while the problem itself (using the most rudimentary algorithm) is quite simple, getting it to work in a multi-threaded fashion does take a little bit of work. In this particular example, the prime finding algorithm can be easily paralleled by utilizing threads and thread synchronization is almost a non-issue since the problem domain can be divided into totally disjoint regions, but in general dividing the problem domain into multiple sub-domains and performing load balancing among them could take significant work. In the following example, I created two C++ classes that both find prime numbers for a given interval (since all prime numbers are odd numbers except 2, 2 is omitted in the calculates below), one sequential and the other parallel. In the main function, both methods are timed and the results are outputted.(download tbbprime.cpp)

#include 
#include 
 
#include 
#include 
#include 
 
#include "tbb/task_scheduler_init.h"
#include "tbb/tick_count.h"
#include "tbb/blocked_range.h"
#include "tbb/parallel_for.h"
#include "tbb/partitioner.h"
 
using namespace std;
using namespace tbb;
 
static const int MAX_SIZE = 1000000;
 
class prime_single_thread
{
public:
    void run(const blocked_range<size_t> &r)
    {
        bool is_prime = false;
 
        for (size_t x = r.begin(); x < r.end(); x+=2)
        {
            is_prime = true;
 
            for (int i = 3; i <= sqrt((double) x); i+=2)
            {
                if (x % i == 0)
                {
                    is_prime = false;
                    continue;
                }
            }
 
            // Output prime numbers:
//            if (is_prime)
//            {
//                cout << x << endl;
//            }
        }
    }
};
 
class prime_tbb
{
public:
    void test_prime(int num) const
    {
        bool is_prime = true;
 
        for (int i = 3; i <= sqrt((double) num); i+=2)
        {
            if (num % i == 0)
            {
                is_prime = false;
                continue;
            }
        }
 
        // Output prime numbers:
//        if (is_prime)
//        {
//            cout << num << endl;
//        }
    }
 
    void operator() (const blocked_range<size_t> &r) const
    {
        for (size_t i = r.begin(); i < r.end(); i+=2)
        {
            test_prime(i);
        }
    }
 
    void run(blocked_range<size_t> r)
    {
        prime_tbb prime_tbb;
 
        parallel_for(r, prime_tbb);
    }
 
};
 
int main()
{
    task_scheduler_init init;
    static tick_count t_start, t_end;
 
    prime_single_thread p1;
    prime_tbb p2;
 
    cout.setf(ios::fixed);
    cout.setf(ios::showpoint);
    cout.precision(2);
 
    //starting from 3, with a granularity of 100.
    blocked_range<size_t> r(3, MAX_SIZE, 100);
 
    t_start = tick_count::now();
    p1.run(r);
    t_end = tick_count::now();
    cout << (t_end - t_start).seconds() * 1000 << " ms" << endl;
 
    t_start = tick_count::now();
    p2.run(r);
    t_end = tick_count::now();
    cout << (t_end - t_start).seconds() * 1000 << " ms" << endl;
 
    return 0;
}

For a very large interval (e.g. 3~1,000,000), the TBB version of the prime program achieved a 4x speed up given a reasonably large grain size (e.g. 100). Smaller grain size resulted in slightly more overhead. On a quad-core machine (Q9450 @ 3.2GHz), it took 217.83 ms for the single threaded routine to find all the prime numbers within 1,000,000, whereas it only took 58.32 ms for the TBB version, which runs roughly four times as fast. The TBB framework took care of dividing the task according to the number of processors automatically.

Develop TBB Using KDevelop and Code::Blocks

kwong — Mon, 02 Jun 2008 01:20:23 +0000

I have been playing around with Intel’s open source TBB (Threading Building Block) recently.The default download includes all the sources that can run on Windows , Linux or Mac OS X. The linux version however, builds using the shell by default and does not support any IDE’s (the Windows version can be built using Visual Studio 2003 or 2005). Even though running TBB applications under any Linux IDEs is not all that different comparing to doing the same under Windows, I found that there were not many tutorials on the Internet on how to do this. So here, I will show you how to setup KDevelop and Code::Blocks for you TBB development and debugging.

KDevelop is a powerful multi-language development IDE that comes as default package for the KDE environment (e.g. Kubuntu). For those who are using GNOME, it can be easily installed via apt-get install (Ubuntu).

The KDevelop IDE is one of the most feature-rich inegrated programming environments on Linux, but unfortunately it is not the easiest to get started due to its overwhelmingly large feature set. Here I will show you what I found the easiest way to set up a project that supports TBB, using the Automake project type.

The version of KDevelop I am using is 3.5.9. The commands might be slightly different in other versions, but the idea should be the same. To start a TBB application, use Automake project type (Projects -> New Projects, under C++ Automake Project, choose Empty Autotools Template.)

Don’t be surprised to see a few dozens of files being created, most of these files are used for program auto-configurations.

For all Automake projects, an active target is needed. So we will need to create an active target. By default, all the targets are configured within the right-hand-side split panels. The name of the active target will be compiled into the binary executable. In my example below, the target is named as tbbdev. In my example, I will use one of the stock program (sub_string_finder.cpp) that came with the TBB source code. It can be found in {TBB Source root}/examples/GettingStarted/sub_string_finder/

In order for the target application to find the shared library at runtime, we need to setup an environment variable LD_LIBRARY_PATH. The setting can be found at Project -> Project Options.

In the example given above, the TBB library source was extracted within my user’s root folder under tbb (/home/kwong/tbb/tbb20_020oss_src/), and the library I used is for 64 bit operating systems. Depending on whether it is debug build or release build, choose library path accordingly.

Next we need to configure the build target. The include paths are configured at the root project level (which is the parent to all configured targets).

the added directory should take the following format: -l{TBB installation root}/include/.

Then we will configure the target library path (this takes place at the active target level):

Note the syntax, the first part (-L) specifies the library path, and the second part (-l) specifies the library name. The actual library is called libtbb_debug.so.

That’s all the settings you will need to compile and run the sample program. Before you start debugging though, make sure that the current target is set to be built in debug mode (For some reason, the default build config does not support debugging and thus you can not set breakpoints within the IDE):

Alternatively, you can also change the compiler flags (CXXFLAGS) to -O0 -g3 (in prorject options).

After the above steps, you should be able to compile, debug and run the sample TBB program from within KDevelop.

As I suggested earlier, Kdevelop might not be the easiest to configure and run since it is mainly geared towards the more complex KDE applications. If you are so used to Microsoft Visual Studio IDEs, you might find Code::Blocks much easier to use.

Start Code::Blocks, and choose File -> New -> Project and choose Console Application. Again, we will use the sub_string_finder.cpp sample code. The library path/include path properties can be set either at the Workspace level (one workspace can contain multiple projects and the settings are inherited unless overwritten) or project level. Assume that we are configuring at the workspace level. Click and highlight the workspace, and choose from menu Project -> Build Options and click on the Linker settings tab. Add the libraries to be linked here:

Note that only the first entry was necessary for this particular project. As you can see from above, you can configure multiple library dependencies here easily. Now click on the Search directories tab, and set up the include path:

Now you can build and debug the application in Code::Blocks.

TBB Benchmarks

kwong — Mon, 12 May 2008 02:18:35 +0000

Since I started using Ubuntu 8.04 as my main operating system, I have been trying to obtain some benchmark information for my month-old new build.

Unlike a machine running Windows, benchmarking suites for Linux are few and far between, and are especially hard to find for 64bit systems. Phoronix does provide an excellent test suite that is designed to run under Linux. But I haven’t had any luck to get the latest version (0.6.0) to build and run properly under the 64bit version of Linux yet. And since most of the applications within the test suite have Linux versions only, it would be very difficult to make cross-OS performance comparisons.

If your primary goal is to test your CPU and memory sub system, then I would recommend using Intel’s open source Threading Building Block (TBB). The source includes a few algorithms that were executed after compilation to test whether the build was successful. As a side benefit, these tests are timed and can be used as benchmarks as well.

As an example, the following list is the benchmark information obtained while building the latest stable version of TBB (tbb20_020oss_src). The library was built on my machine (Q9450 @3.2G, 8GB DDR2-800, Linux 2.6.24-16-generic SMP x86_64)

./count_strings 1
threads = 1 total = 1000000 time = 0.336895
./count_strings 2
threads = 2 total = 1000000 time = 0.214048
./count_strings 4
threads = 4 total = 1000000 time = 0.181645

./seismic – 300
101.5 frame per sec with serial version
102.3 frame per sec with 1 way parallelism
193.9 frame per sec with 2 way parallelism
219.0 frame per sec with 3 way parallelism
244.2 frame per sec with 4 way parallelism

./convex_hull_bench
Starting TBB unbufferred push_back version of QUICK HULL algorithm
Number of nodes:5000000 Number of threads:1 Initialization time:0.293048 Calculation time:0.807145
Number of nodes:5000000 Number of threads:2 Initialization time:0.822569 Calculation time:1.02838
Number of nodes:5000000 Number of threads:3 Initialization time:0.607247 Calculation time:1.13264
Number of nodes:5000000 Number of threads:4 Initialization time:0.5828 Calculation time:1.08477
Number of nodes:5000000 Number of threads:5 Initialization time:0.569491 Calculation time:1.10567
Number of nodes:5000000 Number of threads:6 Initialization time:0.585655 Calculation time:1.09051
Number of nodes:5000000 Number of threads:7 Initialization time:0.583944 Calculation time:1.08213
Number of nodes:5000000 Number of threads:8 Initialization time:0.561563 Calculation time:1.09363
Starting TBB bufferred version of QUICK HULL algorithm
Number of nodes:5000000 Number of threads:1 Initialization time:0.180772 Calculation time:0.713631
Number of nodes:5000000 Number of threads:2 Initialization time:0.09458 Calculation time:0.369742
Number of nodes:5000000 Number of threads:3 Initialization time:0.0698851 Calculation time:0.266026
Number of nodes:5000000 Number of threads:4 Initialization time:0.0567744 Calculation time:0.207367
Number of nodes:5000000 Number of threads:5 Initialization time:0.0555128 Calculation time:0.230236
Number of nodes:5000000 Number of threads:6 Initialization time:0.0598358 Calculation time:0.23095
Number of nodes:5000000 Number of threads:7 Initialization time:0.0624336 Calculation time:0.257518
Number of nodes:5000000 Number of threads:8 Initialization time:0.0586483 Calculation time:0.278667

./primes 100000000 0:4
#primes from [2..100000000] = 5761455 (0.16 sec with serial code)
#primes from [2..100000000] = 5761455 (0.18 sec with 1-way parallelism)
#primes from [2..100000000] = 5761455 (0.09 sec with 2-way parallelism)
#primes from [2..100000000] = 5761455 (0.06 sec with 3-way parallelism)
#primes from [2..100000000] = 5761455 (0.05 sec with 4-way parallelism)

./parallel_preorder 1:4
0.235308 seconds using 1 threads (average of 199.74 nodes in root_set)
0.202356 seconds using 2 threads (average of 199.74 nodes in root_set)
0.153144 seconds using 3 threads (average of 199.74 nodes in root_set)
0.181067 seconds using 4 threads (average of 199.74 nodes in root_set)

./sum_tree
Tree creation using TBB scalable allocator
   half created serially: time = 177.1 msec
   half done in parallel: time = 77.9 msec
Calculations:
           SerialSumTree: time = 77.9 msec, sum=7.01275e+08
   SimpleParallelSumTree: time = 44.5 msec, sum=7.01275e+08
OptimizedParallelSumTree: time = 43.4 msec, sum=7.01275e+08
./sum_tree -stdmalloc
Tree creation using standard operator new
   half created serially: time = 369.2 msec
   half done in parallel: time = 548.7 msec
Calculations:
           SerialSumTree: time = 94.7 msec, sum=7.01275e+08
   SimpleParallelSumTree: time = 65.3 msec, sum=7.01275e+08
OptimizedParallelSumTree: time = 65.4 msec, sum=7.01275e+08