This paper describes an interactive refactoring tool ReLooper for parallelizing loops in Java. It does this by using the Java ParallelArray(an array data structure that supports parallel operations over the array elements) framework, which allows operations to be carried out concurrently by threads on an array. I like this tool as it is interactive and give users a chance to make sure parallelism is done correctly. I think this tool can be very useful to parallelize a loop where each iteration performs its own independent operation. To continue conversation, here are my thoughts on Danny’s questions …
Q1: Sometimes it is possible to retrofit parallelism by refactoring an existing sequential application. Other times the whole system needs to be re-architected for parallelism. What are the advantages / disadvantages of these approaches? When would you do one over the other?
Refactoring a sequential application to parallel will give better performance over all and save cost of making the application to parallel but may leave code and architecture unclean. I may prefer this approach if I have limited resources (people and money to do it) and my application has cleaner architecture in hand and it’s not very big. In this situation, I may be able to covert the application to parallel but still be able to clean the code and architecture as needed.
I may not be able to do above in the case where I don’t have architecture of the application in hand and I don‘t know how the most of the functionalities in the application are implemented (I may be using this as black box in my newer development parts of the application). In this case, conversion may cause more confusion for maintenance and even result in different behavior of the app than required. So, we should go for either full re-architecture for parallelsim.
Q2: There are many libraries that target concurrency and parallelism (e.g., Java's ParallelArray, Microsoft's TPL, Intel's TBB, OpenMP, MPI, etc.). What are the advantages and disadvantages of using parallel libraries?
Libraries will help programmers to implement parallelism quickly and easily without worrying about some of the underlying implementation details. However, programmers may miss opportunities for parallisim overlooking only the available library available items.
Q3: The approach presented in the paper puts the programmer in the driving seat: the programmer selects a snapshot of code, and a refactoring. The process is semi-automated, but not fully automatic. Compare and contrast the refactoring approach with a fully automatic approach, like the one used in automatic parallelizing compilers.
I think each have it’s own benefits and work well for their situations. A fully automated system requires less work and may be better to use it in places where we know we don’t need human interaction to convert them from sequential to parallel, but we will need a semi-automated tool like this one where we know that we need some control how the parallasim is applied to maintain the application integrity.
Q4: Some of the transformations presented in the paper make the code harder to understand (e.g., replacing a loop with a parallel operation). What are some approaches to unclutter the parallel code?
May be some commenting showing or relating the converted items to original code (sequential code) and also maintain neat structure of the code after conversion may help to read it better.
Q5: Automatic loop parallelization has been a long time topic in the Fortran community, with compilers having various degrees of success. Is this problem still relevant for Object-Oriented code? What is different now?
I think the problem is still relevant but more complex. In OO programming we have more complicated concepts like shared objects can be more difficult to detect and account for when parallelizing code.
Q6: The paper presents some empirical evaluation to support the claim that the tool is useful. What are some other factors that you would have liked to see evaluated?
I would like to see actual data size that was run on these cores and also it will be nice to see more details along with table 2 like how much human interaction needed to resolve the conflicts etc.
Q7: The paper presents several program analyses to ensure that loop iterations can run safely in parallel. Are you convinced that these analyses are enough, in other words, can you think about examples that would not be covered by the presented analyses?
Since I haven’t tried the actual tool, it’s hard to come up with a scenario where this tool is not covered but overall paper convenes me that it is safe as it clearly described that it does static analysis on the code before conversion.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment