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!
Freitag, 4. Juni 2010
Software Design Patterns for Parallelization
Welcome back,
it's been some time, but it's been some quality time:
In the last few weeks I've further investigated how to cope with the multicore era as a software engineer.
For this purpose I've collected software patterns, that can be used for code refactorings. For now I can say, that I see a huge benefit of using well-structured source code in sequential code when preparing to go parallel.
So I thought It would be nice to say something about those patterns:
In our lectures on software engineering we tell our students, that the usage of design patterns together with architectural pattern relatively early in the design phase has some huge advantages within the software development cycle. The benefits of these "solutions to recurring problems" called patterns are :
- With every developer having a sound understanding of patterns, the code is much more easily readable and will thus be understood much better.
- Patterns improve the team communication by defining a clear terminology for this specific context.
- Patterns improve both the quality and the structure of source code.
- With patterns, code refactorings like minor or even major revision updates for that software can be achieved much faster
- Patterns support state-of-the-art programming
But patterns also have one tiny, itsy-bitsy drawback:
- Nobody uses them. Ever.
Snap! OK, well...that's a bit too gloomy and pessimistic.But still: Design patterns in software are by far not that frequent, as they should be when you look at the benefits you get. Now, why is that so? One reason for sure is, that not many developers around the globe know about the full potential of software patterns. Within the last few years though, MVC (Model-View-Controller) was one pattern, which finally got some attention due to the strong increase in web applications. The second reason is, that when you don't know what you're doing you can experience problems with patterns you wouldn't have had if you hadn't used patterns. Of course it's not specific for patterns that you can mess things up, when you don't know what you're doing. Nonetheless does this keep people away from patterns... The third reason - maybe the easiest to understand and the hardest to figth against: People do things the way they always did. Design patterns came up in the 1980s and gained some reputation in object-oriented design in the 1990s. Only since the turn of the new millennium are patterns a topic for research in software engineering. So, to many developers this still is relatively new. They didn't grow up with that paradigm and they clearly didn't learn how to program in such a way.
Now, I'm not here today to tell you, that the points of criticism to patterns are invalid. But when you take the time and read about software patterns and use them later on in one of the next projects, you will definitely appreciate the benefits mentioned above because they suddenly come reasonable to you.
When I find the time, I'll come up with a post on Intel's "Parallel Studio 2011" which is currently in beta. It's supposed to help the developer by guiding him through the whole process of parallelizing software.
I'll symbolize the results we got out of the first two real-world projects with a quote from Albert Einstein, who said:
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
K!
[1] - Model-View-Controller pattern (MVC): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[2] - Design Patterns: http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
it's been some time, but it's been some quality time:
In the last few weeks I've further investigated how to cope with the multicore era as a software engineer.
For this purpose I've collected software patterns, that can be used for code refactorings. For now I can say, that I see a huge benefit of using well-structured source code in sequential code when preparing to go parallel.
So I thought It would be nice to say something about those patterns:
In our lectures on software engineering we tell our students, that the usage of design patterns together with architectural pattern relatively early in the design phase has some huge advantages within the software development cycle. The benefits of these "solutions to recurring problems" called patterns are :
- With every developer having a sound understanding of patterns, the code is much more easily readable and will thus be understood much better.
- Patterns improve the team communication by defining a clear terminology for this specific context.
- Patterns improve both the quality and the structure of source code.
- With patterns, code refactorings like minor or even major revision updates for that software can be achieved much faster
- Patterns support state-of-the-art programming
But patterns also have one tiny, itsy-bitsy drawback:
- Nobody uses them. Ever.
Snap! OK, well...that's a bit too gloomy and pessimistic.But still: Design patterns in software are by far not that frequent, as they should be when you look at the benefits you get. Now, why is that so? One reason for sure is, that not many developers around the globe know about the full potential of software patterns. Within the last few years though, MVC (Model-View-Controller) was one pattern, which finally got some attention due to the strong increase in web applications. The second reason is, that when you don't know what you're doing you can experience problems with patterns you wouldn't have had if you hadn't used patterns. Of course it's not specific for patterns that you can mess things up, when you don't know what you're doing. Nonetheless does this keep people away from patterns... The third reason - maybe the easiest to understand and the hardest to figth against: People do things the way they always did. Design patterns came up in the 1980s and gained some reputation in object-oriented design in the 1990s. Only since the turn of the new millennium are patterns a topic for research in software engineering. So, to many developers this still is relatively new. They didn't grow up with that paradigm and they clearly didn't learn how to program in such a way.
Now, I'm not here today to tell you, that the points of criticism to patterns are invalid. But when you take the time and read about software patterns and use them later on in one of the next projects, you will definitely appreciate the benefits mentioned above because they suddenly come reasonable to you.
When I find the time, I'll come up with a post on Intel's "Parallel Studio 2011" which is currently in beta. It's supposed to help the developer by guiding him through the whole process of parallelizing software.
I'll symbolize the results we got out of the first two real-world projects with a quote from Albert Einstein, who said:
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
K!
[1] - Model-View-Controller pattern (MVC): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[2] - Design Patterns: http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
Dienstag, 9. Februar 2010
Parallelism of the future
Hey folks,
as I'm currently working on some form of automatic parallelism in software engineering, I'd like to share my perspective of solving this problem on machines of tomorrow. As I've already mentioned in the post on "Multicore programming - but what comes next" the multicore era of today already belongs to the past, and the future being "manycore" already is the present.
We as software engineers have to think about it today to be able to close the gap that currently exists between the hardware potential and the software engineering expertise. In my studies I find that we need to be able to offer a development environment to the software developer that takes care of certain parallel situations itself. To my mind it's the wrong decision to burden every developer with parallelism specifics. Instead, we as parallel researchers need to figure out a handy way to achieve a certian form of parallelism semi-automatically or even automatically. This is what I'm focusing on.
In the same way virtual machines have been taking over a large part of business software development, AutoParallelism has to be achieved. And just like native code is faster than IL-code, an automatic parallelized application won't be able to speed up just like an applicaion that is developed by a parallel specialst - which is totally OK. If you walk the extra mile you can get the extra speed.
Currently the parallelisation frameworks are very fine-grained: They offer statement-based parallelisation together with statement-based locks. Also, the compiler experts work on automatic compilers that are able to detect parallelizable loops. I'm heading in another direction: Don't detect small jobs and roll them out on multiple processors, but detect large jobs and schedule those. Intel's TechParallel Talk undermines my thesis.
Let's wait and see what I can tell you next time
as I'm currently working on some form of automatic parallelism in software engineering, I'd like to share my perspective of solving this problem on machines of tomorrow. As I've already mentioned in the post on "Multicore programming - but what comes next" the multicore era of today already belongs to the past, and the future being "manycore" already is the present.
We as software engineers have to think about it today to be able to close the gap that currently exists between the hardware potential and the software engineering expertise. In my studies I find that we need to be able to offer a development environment to the software developer that takes care of certain parallel situations itself. To my mind it's the wrong decision to burden every developer with parallelism specifics. Instead, we as parallel researchers need to figure out a handy way to achieve a certian form of parallelism semi-automatically or even automatically. This is what I'm focusing on.
In the same way virtual machines have been taking over a large part of business software development, AutoParallelism has to be achieved. And just like native code is faster than IL-code, an automatic parallelized application won't be able to speed up just like an applicaion that is developed by a parallel specialst - which is totally OK. If you walk the extra mile you can get the extra speed.
Currently the parallelisation frameworks are very fine-grained: They offer statement-based parallelisation together with statement-based locks. Also, the compiler experts work on automatic compilers that are able to detect parallelizable loops. I'm heading in another direction: Don't detect small jobs and roll them out on multiple processors, but detect large jobs and schedule those. Intel's TechParallel Talk undermines my thesis.
Let's wait and see what I can tell you next time
Montag, 16. November 2009
My parallel literal propagation - Speedup and Efficiency
For a computer scientist there is not a lot that satisfies you more than realizing that things work exactly the way you want them to. Even more so, when you have spent quite some quality time on coming that far.
Today I've given the parallel literal propagation module a shot and benchmarked it with some of last years benchmark files. What I see is, that my parallel algorithm scales very well for increasing number of cores or threads. On a fixed number of cores, it even cotinues scaling further when starting more threads than cores are available. This indicates good cache usage, but so far I've not investigated. After all, the speedup is about 5,3 (in comparison to the single-threaded version). I disinguish two different forms of the term 'efficiency' (which relates to the fact, that I can schedule multiple threads on a single processor core). In the traditional sense, the efficiency for the speedup of 5 accounts to 69%, which is an excellent score.
Hopefully, I'll soon be back with further results that prove me right - I'm moving towards parallel unit propagation and conflict detection.
Today I've given the parallel literal propagation module a shot and benchmarked it with some of last years benchmark files. What I see is, that my parallel algorithm scales very well for increasing number of cores or threads. On a fixed number of cores, it even cotinues scaling further when starting more threads than cores are available. This indicates good cache usage, but so far I've not investigated. After all, the speedup is about 5,3 (in comparison to the single-threaded version). I disinguish two different forms of the term 'efficiency' (which relates to the fact, that I can schedule multiple threads on a single processor core). In the traditional sense, the efficiency for the speedup of 5 accounts to 69%, which is an excellent score.
Hopefully, I'll soon be back with further results that prove me right - I'm moving towards parallel unit propagation and conflict detection.
Donnerstag, 12. November 2009
"Research in Europe"
Hi folks,
on Friday I was invited to an informational event on research fundings in Heidelberg, as I'm currently looking for interested and interesting sponsors to support further research. It was organized by KoWi, an institution that coordinates Research and Development throughout Europe and that is funded by the German Research Foundation. It was very interesting to get in touch with the different scholarship programmes and research institutions.
Also, I received very positive feedback on my research plan and ideas - so let's start it up!
on Friday I was invited to an informational event on research fundings in Heidelberg, as I'm currently looking for interested and interesting sponsors to support further research. It was organized by KoWi, an institution that coordinates Research and Development throughout Europe and that is funded by the German Research Foundation. It was very interesting to get in touch with the different scholarship programmes and research institutions.
Also, I received very positive feedback on my research plan and ideas - so let's start it up!
Montag, 2. November 2009
Multicore programming - but what comes next?
For some time now, I'm completely dissatisfied with the technical possibilities, software developers have when writing multithreaded applications. Basic parallel structures like parallel loops and fundamental synchronization mechanisms are definitely needed and it's a good thing programmers have those language constructs at hand. At university today we educate our students to
- be able to use these mechanisms correctly and
- point out the problems, that will most probably still arise when doing it
...well...
At the moment we develop software for 2 up to 32 cores. It might still be feasible for us humans to think that far - to think that parallel - but what if we wake up one nice sunny day and have hundreds of cores on a regular CPU? I mean, what's the point in offering 'parallel-for' when developing software with millions and billions lines of code that should run effectively on hundreds of CPUs? According to Intel and AMD, this day will come. In less then a decade.
Last week I had an interesting conversation with Carsten Schumm from SUN Microsystems. He presented some of the problems they currently experience in engineering multicore-capable applications and solutions. I have been thinking about this problem a lot and I think we need a new programming paradigm.
For now I can say:
I don't know what the solution could be, but I really fancy the idea to be part of it...
- be able to use these mechanisms correctly and
- point out the problems, that will most probably still arise when doing it
...well...
At the moment we develop software for 2 up to 32 cores. It might still be feasible for us humans to think that far - to think that parallel - but what if we wake up one nice sunny day and have hundreds of cores on a regular CPU? I mean, what's the point in offering 'parallel-for' when developing software with millions and billions lines of code that should run effectively on hundreds of CPUs? According to Intel and AMD, this day will come. In less then a decade.
Last week I had an interesting conversation with Carsten Schumm from SUN Microsystems. He presented some of the problems they currently experience in engineering multicore-capable applications and solutions. I have been thinking about this problem a lot and I think we need a new programming paradigm.
For now I can say:
I don't know what the solution could be, but I really fancy the idea to be part of it...
Abonnieren
Posts (Atom)