Intro
In most cases, entirely too many software development dollars are spent on introducing concurrency. Instead programmers should focus on writing serial code which lends itself to concurrency through the judicious use of good algorithms. When serial code is well written, parallelism can be extracted with today's technology.
Our process is built around the goal of helping customers use parallelization as naturally as one would use an optimizing compiler. We provide the dynamic analysis capability to discover semantic concurrency wherever it can be found, saving valuable resources for the customer. This alone is not enough, however, because:
- some code which is legally parallelizeable would reduce performance if parallelized
- some code would be beneficial to parallelize for some machines but not for others
- some code would beneit from nested parallelization, forcing a tedious manual search for the "sweet spot"
- some code is semantically concurrent even though parallelization would modify strict program semantics
Therefore, we also offer the tuning and feedback capability to
- decide which concurrent code to parallelize for the customer's multiprocessing environment
- inform the customer why program regions which could have benefited the most were not parallelized
At the same time, customer feedback in the form of failures in the local regression suite helps us build up a collection of counter example program inputs which should inhibit parallelization of specific code regions.
By closely integrating with the customer's development cycle, we allow the customer to cut through the market clutter and confusion with a simple and effective solution to the parallel programming problem.
Intro
In most cases, entirely too many software development dollars are spent on introducing concurrency. Instead programmers should focus on writing serial code which lends itself to concurrency through the judicious use of good algorithms. When serial code is well written, parallelism can be extracted with today's technology.
Our process is built around the goal of helping customers use parallelization as naturally as one would use an optimizing compiler. We provide the dynamic analysis capability to discover semantic concurrency wherever it can be found, saving valuable resources for the customer. This alone is not enough, however, because:
- some code which is legally parallelizeable would reduce performance if parallelized
- some code would be beneficial to parallelize for some machines but not for others
- some code would beneit from nested parallelization, forcing a tedious manual search for the "sweet spot"
- some code is semantically concurrent even though parallelization would modify strict program semantics
Therefore, we also offer the tuning and feedback capability to
- decide which concurrent code to parallelize for the customer's multiprocessing environment
- inform the customer why program regions which could have benefited the most were not parallelized
At the same time, customer feedback in the form of failures in the local regression suite helps us build up a collection of counter example program inputs which should inhibit parallelization of specific code regions.
By closely integrating with the customer's development cycle, we allow the customer to cut through the market clutter and confusion with a simple and effective solution to the parallel programming problem.