Content and opinions

The book starts with two chapers on what actions to take before parallelizing and what can and what cannot. Before the usual algorithms that can be parallelized, the author takes three chapters to explain how you may achieve your goal. Ensuring correctness is a difficult task, so the book gives 8 rules to help and then an explanation of several support libraries that can be used.

The biggest part of the book, as I’ve hinted, is dedicated to simple but usual algorithms that may be parallelized: sums and scans, mapreduce, sorts, searches, and graph algorithms. Each time, several different algorithms are first coded in a serial way and then parallelized with possibly different support libraries. Also each time, the efficiency, the simplicity, the portability and the scalability conclude the sub art: it helps standing back.

The last chapter is a small overview of the additional tools that you may use (but they are not mandatory). They are mainly Intel’s tools, but it’s mainly because Intel provides the developer with some of the best tools.

Conclusion

Although the author works for Intel, he doesn’t expose Intel tools more than others. The book tone is adequate, not too much serious, not like a “For Dummies”, so just enjoyable.

If you need advices to parallelize your applications and you don’t want to buy Patterns for Parallel Programming, buy this one (well, buy it anyway).

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications
Price: $40.49

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications (Paperback)
by Clay Breshears
ISBN: 0596521537

Price: USD 38.48
40 used & new available from USD 17.99

| 3.5 | 6

Test on parallelizing a custom library

I’ve decided to test Advisor Lite on my Interactive Raytracer. This is a test to verify if Advisor Lite finds the adequate parallelization and the memory sharing issues. It is a simple raytracer, so it can be parallelized for each pixel in the image. The only memory sharing issue that I know of is in the kd-tree ray traversal.

Profiling the library

First, I will profile the library. For the complete Advisor Lite workflow, I have to use Intel Compiler, and as it is faster than Microsoft’s compiler, I will use the timeit_image.py script instead of the measure_image.py I’ve used when profiling with Valgrind or Visual Studio.

Amplifier can show the results in a bottom-up or in a top-down manner. Unfortunately, you only have the exclusive timing that is displayed. In my case, when displaying bottom-up results, the method getEntryExitDistances() is the most costly one. In the top-down view, unfortunately, I can’t have a simple tree, as it can be seen in the following view:

In Visual Studio, I have the same results – more or less -, but with a correct top-down call-tree:

The method getEntryExitDistances() cannot be parallelized: it is recursively called, several times per pixel, which would lead to a lot of memory contention. The simpler task is thus to parallelized the pixel rendering, a perfect data-parallel problem.

Annotation of the code

OK, now I can annotate my code. I had to dig inside the help for this, as it was not mentionned in the Starting Guide that Intel provides a header, annotate.h, which mimics the issues you may encounter in a multithreaded application.

So you need to read at least once the online help so that you know the available annotation macros, how you can get them and how they will retrieve what you need. Once the code is annotated, it must be recompiled and then the sharing issues can be detected.

Detection of sharing issues

As expected, Inspector detected errors in the kd-tree traversal:

The solution in this case is to have a ray-traversal stack per thread, which will have to be implemented in whichever parallel library will be chosen, or simply to put the stack in the actual traversal algorithm and not in the instance.

Using TBB

I’ve decided to go for Thread Building Blocks, as it was already used for game development. This seemed to me a good idea, as it is a Open Source solution. So now, I will split the screen in 2D pieces, and add a thread-specific storage in the kd-tree class. Of course, I will have to add a flag to disable this paralellization if TBB is not available.

The actual parallelization will be in a future post in the Interactive Raytracer category. It is pretty straightforward once I had the different elements Parallel Studio gave me.

Conclusion

In fact Advisor is mainly the annotate.h header, as you have to know your program to put the macros at correct locations. The parallelization must be done by hand, as well as correcting the memory sharing issues.

The only problem I had is that annotate.h includes window.h. This header is not C++ compliant and declares some macros as max() (in fact I got the same issue with TBB headers!). As I use a max() function declared in std::numerical_limits, I had to explicitely undefine this macro.

Safe from this, Advisor Lite is a good plugin, and I’m looking forward to seeing Advisor in a next Parallel Studio release.

Using the profiler

First of all, the code must be compiled with /Zi or /Z7. Then, the link edition must be done with /DEBUG. Without these options, it won’t be possible to measure anything.

Performance Tool must be used in a Visual Studio Solution, which I don’t have in the case of the Interactive Raytracer. I will have to create an empty project, and I will create a bogus project, just to be able to browse the code in the IDE.

Once in Performance Tool, I create a new target which will be my generated library:

Then, I have to add it to the targets to profile:

Then I modify the launch properties to launch python with a sample script that is supposed to be descriptive enough. If you profile a Visual Studio project, you can use the debugging project properties (there are more environment parameters that you may modify).

Sampling

To use the sampling profiler, you have to select it in the session parameters. Once done, you can launch the profiler.

This is the results I got from the IRT:

This view helps finding the function to optimize. It display the current function at the middle of the panel, and then the caller functions at the top and the callee/called functions at the bottom. The displayed costs are inclusive and exclusive costs.

A more general view, the call-tree, can help finding the hotspot as well. The caller can obviously not be displayed.

It is easy to get access to the code by a left click, which is one of the reasons I’ve created a bigus Visual Studio project.

Instrumentation

Instrumentation-based profiling is somewhat different than sampling-based profiling. Here, the executable is modified to count cycles or counters, whereas in sampling-based profile, the program is sampled at regular intervals to get where the program is, the counters, …

Instrumentation results are quite like the sampling ones

Conclusion

According to the different results I got, I know that I have some work to do on the math library. Well, this was some months ago, so now this code optimized as well. Based on Performance Tool profile, a lot has been optimized, as not creating rays inside the loop, …

I cannot really compare Performance Tool to Valgrind, as they are not the same kind of profilers. They each give more or less precise information on some parts of your program.
Compared to KCacheGrind, the callee map is missing, but Microsoft did a great job with the UI. The information may not be visualized as a 2D image, but it is still easy to extract it from the different views.

As a conclusion, I’d simply say that Performance Tool is an excellent tool Mixrosoft provides in its high-end Visual Studio versions. To bad it is not acceissble in the lower versions.