Parallelism in SourcePro
We at Rogue Wave are very aware of what we have termed the multi-core dilemma. The problem is simple: multi-core chips require software concurrency to take advantage of the full processing power. The solution can be very challenging, however, requiring developers to introduce threading or multi-process code into their applications. We have been promoting the ability to achieve parallelism at a service level within our Hydra product line, but within SourcePro we have until now only provided a threading abstraction layer that still requires significant application refactoring if not used initially.
To help improve the ability for our customers to take advantage of multi-core architectures, we are currently investigating ways to introduce parallelism within some of our current SourcePro classes. The easiest area to add parallelism “under the hood”, so to speak, is in areas where there is read-only access occuring. For these cases, we maintain safety in performing parallel operations that hopefully would require no code changes for our customers.
To ensure that introducing parallelism where it previously didn’t exist will not cause issues with existing use of the products, we are looking to make activation of the parallel code occur from a switch type mechanism. We could provide a new build flag, an environment variable or other options to allow the developer to easily test the new operations, and switch back to the existing implementations if necessary.
Areas we are looking at include search methods on RWCString, methods on collections for sorting and search with iterators, as well as new higher level parallel algorithms that we could add to SourcePro DB. We are actively soliciting feedback from our customers on which classes and methods are used most frequently, as well as ideas on where parallelism could provide the most benefit. Please comment with your ideas and interests to help us maximize the benefit from these new enhancements.
Del.icio.us | Technorati | Digg | Slashdot