Welcome back,
as I wrote in my last posting on unit tests, they can be used to get a runtime profile for a certain region that you are interested in. One general shortcoming of unit tests when testing the inner structure of a method or region is, that they that focus on behavior that can externally be seen. We propose an alternative usage of the assertion mechanism in order to measure the performance profile of a method in its inner body. Without our approach you would have to restructure your code to get this kind of information. At the same time this would also changes the timing behavior. When dealing with concurrent programming this is exactly, what you don't want. When monitoring the performance what you would do today is let a profiler run you application which captures everything you can get. This ends up in a huge pile of runtime information that might not even be relevant for the region you are interested in. As I've mentioned before: A parallel application is a queue of sequential and parallel code. The pearl neckless. Remember?!
Throughout an application there are many different parameters that affect the runtime behavior, reaching from general aspects such as the design pattern that is used to describe the architecture, to more specific ones such as the number of threads executing an application or the size of global data structures. The concrete value of each parameter can be manifold and is orthogonal to all other parameters. Thus, each parameter defines one dimension in a hypercube depicting the complexity space of an application. It can easily be seen that already a very small application with -let's say- 5 parameters results in a 5-dimensional cube.
Now, what's got all this to do with performance optimization and the pearl necklace you might ask? Calm down and relax. I'll get to it: When capturing the whole application and deducing parameters along the way, you easily end up inside exploding space due to the complexity. Instead, our approach enables you to focus on certain regions of interest. You can at first focus on those areas of sequential code that use most of the runtime and focus on monitoring those parallel regions alongside the whole development phase. Also, we keep a history table to be able to capture and analyze the effects changes had on your "pearls".
K!
Mittwoch, 20. Oktober 2010
Mittwoch, 6. Oktober 2010
Enhancing Unit Tests for Performance Monitoring #1
Hey folks,
in the past several weeks I've eagerly tested Intel's Parallel Studio. I got my hands on the beta release and tested it against some common parallel problems and I went on working on the parallelization only in September. Since then though, I have been developing an approach combining software patterns with unit tests I'd like to share with you. In the next weeks I'll be coming up with further performance aspects.
Our research works in this field show that parallel applications can basically be seen as sequential code with parallel regions of code embedded in between. I might be using the metaphor of a "pearl necklace" now and then, because I like the idea that the pearls are arranged one after another and that they are the precious spots that harbor parallel potential.
Recently, some quality work has been done around unit tests, that attracted my attention. I'm currently working on a test-based way to detect parallelization potential in sequential applications. Now, everybody that is familiar with that topic knows that unit test frameworks don't support this out-of-the-box, so we're just about to enhance it ourselves. The new thing about our approach is that unit tests can then not only assert Boolean conditions for fields or return-types. Assertions can then also account for memory consumption, cache-evicts or other counters that might not be uninteresting to those dealing with parallelization. As the test runs repeatedly execute alongside the development process, our approach can also be used to monitor performance changes that occur in the course of code refactoring.
So now you can more easily focus on the essentials - the pearls - and leave the rest out.
K!
in the past several weeks I've eagerly tested Intel's Parallel Studio. I got my hands on the beta release and tested it against some common parallel problems and I went on working on the parallelization only in September. Since then though, I have been developing an approach combining software patterns with unit tests I'd like to share with you. In the next weeks I'll be coming up with further performance aspects.
Our research works in this field show that parallel applications can basically be seen as sequential code with parallel regions of code embedded in between. I might be using the metaphor of a "pearl necklace" now and then, because I like the idea that the pearls are arranged one after another and that they are the precious spots that harbor parallel potential.
Recently, some quality work has been done around unit tests, that attracted my attention. I'm currently working on a test-based way to detect parallelization potential in sequential applications. Now, everybody that is familiar with that topic knows that unit test frameworks don't support this out-of-the-box, so we're just about to enhance it ourselves. The new thing about our approach is that unit tests can then not only assert Boolean conditions for fields or return-types. Assertions can then also account for memory consumption, cache-evicts or other counters that might not be uninteresting to those dealing with parallelization. As the test runs repeatedly execute alongside the development process, our approach can also be used to monitor performance changes that occur in the course of code refactoring.
So now you can more easily focus on the essentials - the pearls - and leave the rest out.
K!
Abonnieren
Posts (Atom)