Firstly, it was very nice to see a paper build directly off the work of a recent, previous paper, and the use of the ForkJoinFramework here was a great idea.
Q1) The biggest advantage to retrofitting these techniques into your project is the cost. Designing and implementing a project to be multicore ready is a wonderful idea to get the best performance you can, but often in the business world the create recreation of your project may simply be impossible. A tool that can go in and automatically produce performance gain in a controlled and trusted manner is a boon to developers and users alike. The only reason I can come up with to build an application from scratch is, as I have stated in other postings, if the project's performance is its key metric. In these cases designing from the ground up is the only way to ensure that performance is the best you can make it. The other advantage besides cost in using a refactoring tool is that the retraining of the developers is much less, as they only need to understand how to use the new tool rather than totally relearn their craft to accommodate this new skill.
Q3) My biggest issue with using a totally automated tool, and the nice thing about having to select what to apply the refactoring to is that it may not be necessary to fully parallelize all aspects of a program. Things like application login, some perference control and other relatively simple tasks would gain nothing from the additional effort behind doing these transformations. The code would simply be hid behind this strange exterior.
Q4) One of the things I was wondering about when reading the code was if there was thought given to simply overloading some of the traditional operators to work the way we expect them to while looking the way we are used to. It would be impossible in all cases but about 10 of the entries in Table 1 should be able to have this done to them. This would certainly reduce a lot of developer strain on the basic operations for the first two transformations styles (which the paper cites as being the most frequent by far). This would also reduce effort on the part of developers trying to program using these data structures on their own.
Q6) The biggest issue I had while reading this paper was the mention early on and several other times that this may not be a totally thread safe solution. Given the habit of many professionals to trust their tools this worries me greatly. Gathering clear metrics on the failings of the system would be nice, and a discussion of why they occur (beyond simply "code complexity") would be genuinely interesting. This also seems to be a place that the development team for this tool will need to be focused for a long time, as a faster program that is not correct is going to only be mostly useful.
Still, this is a great tool and I can't wait to start seeing it and others like it adopted in a widespread manner until we as developers are used to parallelization smells.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment