This introductory chapter accomplished two things: it did an excellent job of laying the foundation that will be expanded upon in later chapters and it whet my appetite. Since both of these things were accomplished I would consider that a resounding success.
At first while reading I was concerned as to why the author insisted that current Object Oriented languages would not be enough to complete the level of concurrency aimed at since it seemed that all that was occurring was the layering of additional interfaces and basic constraints over a current thread like architecture. It wasn't until the listings near the end of the chapter that stressed things like run-time code and library alteration that I began seeing why it was necessary to go beyond Java or C/++/#. It would have been nice to see the requirements listing for the OS, Language, Libraries, and other parts near the front of the chapter so that readers like me aren't spending the brain power asking "Why can't we just..." when the author has clearly already thought that through. There was one comment in the Operating System requirements section that I disagreed with greatly, namely that if the OS can create and destroy threads quickly then this is good enough to assume that this approach will scale well to systems with a large number of threads. I find this to be dangerous and short-sighted, to think that only at creation and destruction do threads add computational overhead to CPU work. Perhaps later sections will delve further into this. I can only hope.
The Next thing that really caught my eye was the introduction to security. The idea that a process or program needs the PID for access is an obvious one and the author correctly identifies that it will be the flow of this information that will expose security risks (assuming of course that choosing a PID is a sufficiently obfuscated process). When I got to those bullet points it raised a few questions about how they were actually going to tackle these issues, but unfortunately that sounds as though it will have to wait for later. Also somewhere in there is a concern about all messages passed are going to be atomic and how they exactly propose to pull this off.
Finally, it will be interesting to see if programming in such an environment is really going to be as easy and intuitive as the author claims it will be. Again though, this sounds like it will have to wait until later chapters are read.
All in all, it was an interesting start. I haven't found any horrible flaws yet which is always encouraging in a paper of this size, and the authors have done a good job of laying the foundation for what is to come.
Monday, October 19, 2009
Event Based Notification and Map Reduce
To begin, I felt that the Event Based Notification added very little to the generally known observer pattern. The only real differences I was able to spot was that there was a discussion of choosing the correct medium to transmit messages, such as a bus, and then briefly mentions that it may be necessary to consider notifying listeners on other threads. The specialization of this system seems to be in that all objects on the medium will receive and check the message sent to see if they are concerned about its content and act appropriately as opposed to a system where objects must register with some central authority about the type of event they wish to be notified of. The method outlined in the paper does have the advantage of not needing to maintain a listing of objects that must be broadcasted to which is nice when the system gains many objects that want notification. However, if there are a large number of objects then this tactic looses some of its luster, as many messages must be sent to objects that have no interest in the contents and time must be spent checking which state this object falls in. So, it is best to determine not only the projected growth of the system's objects but also how many objects are expected to actually need to listen for events. If there are many objects but only a few that need contacting then an explicit list will add overhead at creation but will reduce it during normal operation. As for error handling, a given component needs to know how critical the proper reception and execution of a message is. So, while it will probably fall to the medium to detect if all notifications have all occurred (and rectify any misses in the same way most internet packets do find their way) it should be up to the component to determine what it should do with faulty input. No blanket approach is going to satisfy all conditions but my intuition is that the central authority should only be contacted in cases of dire failures.
For the Map Reduce paper I was sad to see such little attention paid to the important steps of actually constructing the summary. Since the application of threads to collect data and use it to derive some basic further information should not be difficult at this stage the trick seems to be in constructing a way to intelligently combine the results in a way that does not sacrifice the efficiencies of the mapping. Unfortunately this paper seemed to be more focused on the general idea of Map-Reduce rather than on the actual application of it, seeming to leave the majority of the work to those Parallel Computing Gurus mentioned in the paper. Nor is there much discussion of creating a way for domain specialists to interact with a system that could ease their use of a Map-Reduce framework. The idea of an extendable framework that allows for both the easy identification of data sets, the mathematical analyses that wish to be performed and the expected output format would be an intriguing system to help construct.
For the Map Reduce paper I was sad to see such little attention paid to the important steps of actually constructing the summary. Since the application of threads to collect data and use it to derive some basic further information should not be difficult at this stage the trick seems to be in constructing a way to intelligently combine the results in a way that does not sacrifice the efficiencies of the mapping. Unfortunately this paper seemed to be more focused on the general idea of Map-Reduce rather than on the actual application of it, seeming to leave the majority of the work to those Parallel Computing Gurus mentioned in the paper. Nor is there much discussion of creating a way for domain specialists to interact with a system that could ease their use of a Map-Reduce framework. The idea of an extendable framework that allows for both the easy identification of data sets, the mathematical analyses that wish to be performed and the expected output format would be an intriguing system to help construct.
Wednesday, October 14, 2009
Heisenbugs in Concurrent Programs
Overall, this is my favorite paper so far this semester. It focuses on a tool that is released and being used in actual projects and not just as part of an academic environment which I quite like to see. The level of detail presented could have been better for some of the sections though. Their brief mention of how long it took to hook CHESS into an existing program was nice (and at one hour didn't sound too horrible) though it could have used with a more concrete discussion of what that involved. Running the tool against Singularity's boot sequence was an interesting touch, and that it found a bug is fantastic (how horrifying would it be to find your computer freeze or at least lose resources to a spinning thread.
The thing I liked the most about this product was definitely the robustness of the test platform. Its ability to semi-intelligently identify possible concurrency issues was cool, but by far the stand up features were the comprehensive test reports (enough to allow the engineer to target the condition that causes the error directly) and the ability to skip through the test set CHESS generates to a specific run is a great idea. I hate having to wait through several tests that I know will pass when all I'm looking for is to see if the changes I've just made actually fix what was intended. Allowing users to jump immediately to that broken test case is going to save quite a bit of time and aggravation. And 30 seconds for several thousand test case runs is not a bad trade off in that instance.
I suppose the only drawback right now is the effort that is required to extend this tool into new environments, and while I certainly appreciate the ability for this tool to work in the Windows environment I can already hear the calls to liberate this code so the *NIX can have its chance.
The thing I liked the most about this product was definitely the robustness of the test platform. Its ability to semi-intelligently identify possible concurrency issues was cool, but by far the stand up features were the comprehensive test reports (enough to allow the engineer to target the condition that causes the error directly) and the ability to skip through the test set CHESS generates to a specific run is a great idea. I hate having to wait through several tests that I know will pass when all I'm looking for is to see if the changes I've just made actually fix what was intended. Allowing users to jump immediately to that broken test case is going to save quite a bit of time and aggravation. And 30 seconds for several thousand test case runs is not a bad trade off in that instance.
I suppose the only drawback right now is the effort that is required to extend this tool into new environments, and while I certainly appreciate the ability for this tool to work in the Windows environment I can already hear the calls to liberate this code so the *NIX can have its chance.
Pipes, Layers, and Iterative pattern
We read three brief papers, two on patterns we have covered earlier and one on a new "pattern".
The first was a review of the pipes and filters pattern, wherein a system is engineered to allow reusable modules to tackle sequential inputs. The idea in this paper of likening this process to the way a graph flows is an interesting idea and could help with the constructing of shared modules as common breaking points can be identified. The very brief mentions of how to parallelize programs using this pattern if welcome, but for a wiki it is awfully short on links to the appropriate pattern details. Considering how brief this whole section is it should not have been difficult to build a similar page for the mentioned patterns or link to their main wiki counterparts. More care could have been taken to discuss how to identify and construct the modules and their interfaces, including leveraging existing technologies like XML for these specifications. Overall this was a decent introduction to the pattern, but like the next two entries lacked the meat really needed to make this anything other than a guidepost.
The Layered Pattern follows much the same format, being a decent guidepost but lacking the detail necessary to use this as a guide for constructing programs according to this pattern. It keeps talking about making sure to get to the "minimum" number of layers with absolutely no direction other than you may want a layer to talk to hardware. I was convinced until I reached the example that you can just as easily have called this paper "Model View Controller" and changed nothing. Since this pattern is impossible to apply correctly without rigorous effort identifying the correct splitting points between layers I'm surprised there was no actual discussion on how one would accomplish this. Other than some vague references to TCPIP and a poorly described robot-controlling piece of software there was little actual content to this. A disappointment, even for the length of this paper.
The Iterative Refinement pattern is an interesting case. It seems from the discussion that it is applying parallelization to the standard recursive model of problem solving. This reminds me very much of what was discussed in the ReLooper paper where it was talking about building array loop parallelizers, only instead of iteratively going over specially designed datatypes we are applying the same thought to independent, recursive problems. It seems to me that making these calls parallel is not where the difficulty in this pattern lies. Indeed, the ForkJoin Framework paper even discussed applying itself to problems like this one. The focus of a paper like this should be on guiding an engineer through identifying when this can be applied and possible steps to take to modify current solutions to apply to this approach.
The first was a review of the pipes and filters pattern, wherein a system is engineered to allow reusable modules to tackle sequential inputs. The idea in this paper of likening this process to the way a graph flows is an interesting idea and could help with the constructing of shared modules as common breaking points can be identified. The very brief mentions of how to parallelize programs using this pattern if welcome, but for a wiki it is awfully short on links to the appropriate pattern details. Considering how brief this whole section is it should not have been difficult to build a similar page for the mentioned patterns or link to their main wiki counterparts. More care could have been taken to discuss how to identify and construct the modules and their interfaces, including leveraging existing technologies like XML for these specifications. Overall this was a decent introduction to the pattern, but like the next two entries lacked the meat really needed to make this anything other than a guidepost.
The Layered Pattern follows much the same format, being a decent guidepost but lacking the detail necessary to use this as a guide for constructing programs according to this pattern. It keeps talking about making sure to get to the "minimum" number of layers with absolutely no direction other than you may want a layer to talk to hardware. I was convinced until I reached the example that you can just as easily have called this paper "Model View Controller" and changed nothing. Since this pattern is impossible to apply correctly without rigorous effort identifying the correct splitting points between layers I'm surprised there was no actual discussion on how one would accomplish this. Other than some vague references to TCPIP and a poorly described robot-controlling piece of software there was little actual content to this. A disappointment, even for the length of this paper.
The Iterative Refinement pattern is an interesting case. It seems from the discussion that it is applying parallelization to the standard recursive model of problem solving. This reminds me very much of what was discussed in the ReLooper paper where it was talking about building array loop parallelizers, only instead of iteratively going over specially designed datatypes we are applying the same thought to independent, recursive problems. It seems to me that making these calls parallel is not where the difficulty in this pattern lies. Indeed, the ForkJoin Framework paper even discussed applying itself to problems like this one. The focus of a paper like this should be on guiding an engineer through identifying when this can be applied and possible steps to take to modify current solutions to apply to this approach.
Tuesday, October 13, 2009
Rereading the classics
Like a few others in this class I have just taken special topics 598 over the summer which focused on Smalltalk and its strict use of object oriented programming. As a result much of this chapter was a review of materials for me so I wasn't as engaged as I could have been. I will say though that this paper was very much a rambling mass of concepts that seemed to be related but it could have been made much more explicit. To begin by breifly talking about how often Noam Chomsky is quoted, compare that the the Gang of Four in Software, then discuss Smalltalk's architecture is a strange flow without a much more explicit attempt to clarify the links.
Overall, as I believe I've mentioned before that I had a bit of experience in Smalltalk, I can say that it is a powerful and flexible language that allows for a lot of interesting tricks. With its strong focus on small, modular classes and methods breaking down a problem into manageable pieces is pretty straightforward, and with Squeaks built in code refactoring tools its easy to accomplish. However, much like the comments on Functional programming, such small modular pieces can make keeping track of large enterprise sized system a pain. With it's focus on typing, inheritance, and other object oriented focuses (and the handy package organization techniques) it will be easier to logically organize systems to allow for the handling of large programs, but in the class project I can remember a few times still getting lost in what was going on because of all the methods and submethods.
Overall, as I believe I've mentioned before that I had a bit of experience in Smalltalk, I can say that it is a powerful and flexible language that allows for a lot of interesting tricks. With its strong focus on small, modular classes and methods breaking down a problem into manageable pieces is pretty straightforward, and with Squeaks built in code refactoring tools its easy to accomplish. However, much like the comments on Functional programming, such small modular pieces can make keeping track of large enterprise sized system a pain. With it's focus on typing, inheritance, and other object oriented focuses (and the handy package organization techniques) it will be easier to logically organize systems to allow for the handling of large programs, but in the class project I can remember a few times still getting lost in what was going on because of all the methods and submethods.
Monday, October 12, 2009
Refactoring for Reentrancy
I was spectacularly unimpressed by this paper and the Reentrancy tool. There are three strikes against it by my count. First is it's poor applicability, second is its poor performance gain, and third is its ability to damage exceptions.
Several times throughout the paper it is mentioned that this tool does not correctly handle programs that interact with their environment, including the use of the standard system output, accessing files, and accessing databases (not explicitly mentioned but heavily implied by its inability to handle other environmental data sources). Too many programs, especially ones that put enough strain on a system to justify multiprocessing rely on access to these outside data sources as a necessity, and having to completely re-work your program to handle and remove these things is going to be too much of a headache in any major application. While it makes perfect sense that this is necessary it removes too many programs from having this applied right out of the gate (without significant work on accessing libraries to better handle these accesses).
Secondly, the performance gain, in only 3 out of 5 test benchmarks does not give this refactoring program a passing grade. While that is a harsh assessment the authors even admit point blank that the performance gain in these 3 points is small. Big enough to notice but not large enough to have a big impact on the overall program efficiency. Given the amount of rework that will be necessary to get most modern programs to a point where you can apply the reentrancy tool I'm unconvinced that the meager performance gains are worth the trouble.
Which brings me to the last major issue. On page 7 the authors make note that their program cannot guarantee that certain structures remain coherent concerning exceptions. They also make the rediculous claim that "typically this does not pose problems". While I would agree that many exception statements are added in order to conform to coding standards or library usage and thus aren't added directly by choice of the programmer anything that makes a program less stable and helpful during debugging is something to generally avoid. I keep thinking of trying to find the root cause of some memory issue, going through the stack trace then being stopped when the reentrancy tool has broken the trace. That would make for some gloriously frustrating time.
So, with its performance gains small, its ability to break debugging when we only have the authors' assurances that this is an edge case, and with its inability to handle data accesses of any sort this tool clearly needs a lot of work to demonstrate true usefulness for the industry.
Several times throughout the paper it is mentioned that this tool does not correctly handle programs that interact with their environment, including the use of the standard system output, accessing files, and accessing databases (not explicitly mentioned but heavily implied by its inability to handle other environmental data sources). Too many programs, especially ones that put enough strain on a system to justify multiprocessing rely on access to these outside data sources as a necessity, and having to completely re-work your program to handle and remove these things is going to be too much of a headache in any major application. While it makes perfect sense that this is necessary it removes too many programs from having this applied right out of the gate (without significant work on accessing libraries to better handle these accesses).
Secondly, the performance gain, in only 3 out of 5 test benchmarks does not give this refactoring program a passing grade. While that is a harsh assessment the authors even admit point blank that the performance gain in these 3 points is small. Big enough to notice but not large enough to have a big impact on the overall program efficiency. Given the amount of rework that will be necessary to get most modern programs to a point where you can apply the reentrancy tool I'm unconvinced that the meager performance gains are worth the trouble.
Which brings me to the last major issue. On page 7 the authors make note that their program cannot guarantee that certain structures remain coherent concerning exceptions. They also make the rediculous claim that "typically this does not pose problems". While I would agree that many exception statements are added in order to conform to coding standards or library usage and thus aren't added directly by choice of the programmer anything that makes a program less stable and helpful during debugging is something to generally avoid. I keep thinking of trying to find the root cause of some memory issue, going through the stack trace then being stopped when the reentrancy tool has broken the trace. That would make for some gloriously frustrating time.
So, with its performance gains small, its ability to break debugging when we only have the authors' assurances that this is an edge case, and with its inability to handle data accesses of any sort this tool clearly needs a lot of work to demonstrate true usefulness for the industry.
Thursday, October 8, 2009
ReLooper
The first major comment I have on this tool is that I am confused as to why this is a separate tool from the one in the previous paper. Both are heavily focused on the refactoring of your program for enhanced parallelization with the first focusing on recursive functions and this paper focusing on array operations. Both tools seem to be very helpful on their own, and both do show a marked improvement in performance on a system, and both use the ForkJoinTask framework as their basis so it seems that a melding of the two projects into a single refactoring tool would be a grand idea to push performance even higher. I would love to see your group crunch the numbers on the combined performance of the two tools presented so far.
Another issue is the choice of hosts. While a site specifically aimed at refactoring is a logical place to put this tool I am afraid that the tool (and the tool presented previously) are not going to get the exposure they need. As we've discussed in class parallelization is not going to go away and companies and individuals are all going to be looking for the tools to help them get this done in a cost-effective way. So there is already and will be an increasing demand for these tools. And the chioce of working directly inside the Eclipse environment is a great one since that is a widespread IDE. But why not host this inside Eclipse's own addon network? A tool like this needs exposure to get the use it should have, and tucked away in a site away from the first place all developers will look for their addons is not the best approach.
Finally, the fact that the two tools were separated makes perfect sense in the world of academia. Afterall, part of the goal there is to publish as much as possible. In a perfect world the author team or a group closely associated with them would be bundling these advances into a single master tool suite for automated parallelization refactoring. Perhaps a corporate partnership or an appeal to the Open Source community to assist in packaging and refining of the tool itself. I am afraid that by placing the tool in an out-of-the-way location and making multiple publishings on what could easily be the same tool will lead to the death of the project. If after all these papers have been produced the authors move on to new refactoring paths or other areas of interest then this will whither on the vine and programmers will not only be denied a handy tool to make their development easier it will also force at least one other group (though most likely more) to reinvent the wheel. And isn't one of the big things in Software Engineering to build your modules for continued reuse, improvement, and maintenance with an understanding that it will probably not (with any success) be only you working on it in the future?
Another issue is the choice of hosts. While a site specifically aimed at refactoring is a logical place to put this tool I am afraid that the tool (and the tool presented previously) are not going to get the exposure they need. As we've discussed in class parallelization is not going to go away and companies and individuals are all going to be looking for the tools to help them get this done in a cost-effective way. So there is already and will be an increasing demand for these tools. And the chioce of working directly inside the Eclipse environment is a great one since that is a widespread IDE. But why not host this inside Eclipse's own addon network? A tool like this needs exposure to get the use it should have, and tucked away in a site away from the first place all developers will look for their addons is not the best approach.
Finally, the fact that the two tools were separated makes perfect sense in the world of academia. Afterall, part of the goal there is to publish as much as possible. In a perfect world the author team or a group closely associated with them would be bundling these advances into a single master tool suite for automated parallelization refactoring. Perhaps a corporate partnership or an appeal to the Open Source community to assist in packaging and refining of the tool itself. I am afraid that by placing the tool in an out-of-the-way location and making multiple publishings on what could easily be the same tool will lead to the death of the project. If after all these papers have been produced the authors move on to new refactoring paths or other areas of interest then this will whither on the vine and programmers will not only be denied a handy tool to make their development easier it will also force at least one other group (though most likely more) to reinvent the wheel. And isn't one of the big things in Software Engineering to build your modules for continued reuse, improvement, and maintenance with an understanding that it will probably not (with any success) be only you working on it in the future?
Wednesday, October 7, 2009
Object Oriented vs Functional
I'll start this off with the caveat that I have not had much personal experience with functional languages, so take what I say with a grain or so of salt.
One of the things that I liked about this paper was that they clearly laid out everything that could immediately be considered wrong with it at the beginning. That they would acknowledge the small sample size, author bias, and other factors like that is very nice to see because it allows me the ability to immediately start adjusting my expectations to compensate. Seeking another source to help offset that is also a welcome touch.
The main advantage, which was talked about in the Emacs paper, and from what I've seen from systems built using functional languages is that because everything has been deconstructed to small modules and functions extending the functionality is a very quick process. Everything you need is typically there in that function call, so it is up to you to do what you'd like to the output to get at your own needs. This seemed to be the strength of the Emacs construction, which demonstrated the power and flexibility of that approach. But the issue for me is that this same power and flexibility can make maintaining a hierarchy much more difficult since developers get the access they want to the functions they want where ever they want them. With and object-oriented system you can set up interfaces, scopes, and inheritance patterns so that extending functionality can be done relatively painlessly, but still maintain the control over component access. Of course, as we spent the whole first portion of this course saying that if you're going that route you better have a good architect so the system doesn't become prohibitively complex or pointlessly over-layered.
When it comes to designing and your languages impact it seems that the purpose of the language drives the focus of your efforts. Functional languages naturally build from small problems into larger ones, so the breakdown of problems into small tasks is going to be the guiding force behind your construction architecture. Care will have to spent (as this article discussed) in making sure that the tasks can work in such a way that the problem you're abstracting still gets solved with enough generality that it is useful and reusable. Whereas the way we're taught to approach object-oriented software design is to breakdown the problem space into nouns and model those first, then their interactions. So we arrive in roughly the same location, it's just a matter of if we're concentrating on "bake pudding" or "bake pudding".
One nice feature of functional languages is that since the concentration is on breaking a problem down into small methods that each solve an individual part of the problem it should not be too difficult to start separating independant sections of the problems into tasks that can be shipped off to different processors.
@Randy Blamo: Fruit Salad
Yummy yummy
One of the things that I liked about this paper was that they clearly laid out everything that could immediately be considered wrong with it at the beginning. That they would acknowledge the small sample size, author bias, and other factors like that is very nice to see because it allows me the ability to immediately start adjusting my expectations to compensate. Seeking another source to help offset that is also a welcome touch.
The main advantage, which was talked about in the Emacs paper, and from what I've seen from systems built using functional languages is that because everything has been deconstructed to small modules and functions extending the functionality is a very quick process. Everything you need is typically there in that function call, so it is up to you to do what you'd like to the output to get at your own needs. This seemed to be the strength of the Emacs construction, which demonstrated the power and flexibility of that approach. But the issue for me is that this same power and flexibility can make maintaining a hierarchy much more difficult since developers get the access they want to the functions they want where ever they want them. With and object-oriented system you can set up interfaces, scopes, and inheritance patterns so that extending functionality can be done relatively painlessly, but still maintain the control over component access. Of course, as we spent the whole first portion of this course saying that if you're going that route you better have a good architect so the system doesn't become prohibitively complex or pointlessly over-layered.
When it comes to designing and your languages impact it seems that the purpose of the language drives the focus of your efforts. Functional languages naturally build from small problems into larger ones, so the breakdown of problems into small tasks is going to be the guiding force behind your construction architecture. Care will have to spent (as this article discussed) in making sure that the tasks can work in such a way that the problem you're abstracting still gets solved with enough generality that it is useful and reusable. Whereas the way we're taught to approach object-oriented software design is to breakdown the problem space into nouns and model those first, then their interactions. So we arrive in roughly the same location, it's just a matter of if we're concentrating on "bake pudding" or "bake pudding".
One nice feature of functional languages is that since the concentration is on breaking a problem down into small methods that each solve an individual part of the problem it should not be too difficult to start separating independant sections of the problems into tasks that can be shipped off to different processors.
@Randy Blamo: Fruit Salad
Yummy yummy
Monday, October 5, 2009
Refactoring Sequential Java Code for Concurrency via Concurrent Libraries
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.
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:
Posts (Atom)