The paper describes an approach to hybrid static/dynamic activity analysis and numerical results applying the approach to a set of test problems. This is a worthwhile subject and it is very nice that somebody makes a serious attempt to get answers. I expect this to be of continued interest. The idea of combining static and dynamic analysis has been around for some time but it remained unclear what can be gained for practical applications. The paper nicely describes the approach and the numerical experiments give some insight on what might be possible. However, in order to be useful as a basis for continued research it also needs to establish a reference implementation to enable comparisons. The paper appears to indicate though that neither one of the two AD tools used in the numerical experiments actually have a usable implementation of what is presented here. The must-may analysis is implemented with the help of OpenAnalysis. It is stated that ADIC 1.2 does not use this analysis provided by OpenAnalysis. OpenAD does use OpenAnalysis but appears to generate code based only on the results of the may activity analysis. I.e. it likely could not generate code that supports dynamic analysis and it is hinted that it may support this in the future. I understand that these gaps are in part bridged with some manual modifications to the generated code. It remains unclear how complex these modifications are. If they are simple one might ask why they haven't been implemented. If they are more complicated one has to ask how much of the observed speedup is really due to the manual code changes vs just the more naive use of the refined activity analysis. Consequently, the readers will find it very difficult to reproduce the results for their own applications and we don't have a reference. I am not sure you can address the implementation issue in time for the workshop. I recommend deferring the publication until this is addressed. Author response: Your assessment is fair. We submitted our paper as a record of progress: the results we have so far. You are correct in that we could not address all of the implementation issues you raise in time for the workshop. This is a work in progress, and while some issues have been addressed in time for the final paper, more will be addressed before the May presentation. The modifications that are done by hand are not complex, just time-consuming. They have not yet been incorporated into OpenAD due to dependence upon different branches of OpenAnalysis code. minor issues: The abstract mentions an average speedup of 28%. It is not clear to me where in the presented individual benchmarks this 28% average shows up. It is mentioned prominently so there should be a reference to the results supporting this claim within the paper. Author response: pg 1, 2nd paragraph" typo "convervative" ^ I had to read the sentence with this typo a couple of times to parse it properly. May be it would be easier to understand if it is rephrased as: "Unfortunately, static activity analysis (done at compile time) may, in the presence of control flow, be too conservative. On the other hand, dynamic activity analysis (done at runtime) may introduce a significant amount of overhead." Author response: problem addressed and sentence(s) rewritten. pg 1/2: The 55% overhead on Fortran and the 28% speedup on the C benchmarks begs the question, what is the overhead in C and what is the speedup in Fortran? It is also not clear against what baseline the speedup is gained. While this comes later it would be good if you forward reference or make this clear right away. Author response: We have stipulated the baseline against which the speedup is gained at this point in the paper. pg 3: caption of Fig 3: use {\tt flag} and may be when you talk about flag being true or false you can declare it bool instead of int. Author response: problem addressed and rewritten pg 3: first paragraph: "The control-path ... not deterministic" I would suggest to use "not decidable at compile time" instead of "not deterministic". The latter to me sounds like you want to say that the control path is completely random but hopefully flag will have been set at run time. Author response: problem addressed and rewritten pg 3: second paragraph last sentence, I vaguely remember being taught not to start a sentence with "But" or "And" etc. But I may be wrong :-) Author response: Good point. "But" omitted. pg 3 last paragraph: insert "... implemented as C preprocessor macros." ^^^^^^^^^^^^^^ Author response: inserted. pg 4 first paragraph last sentence say "during the execution of" or replace "during" with "in" Author response: replaced with "in". pg 4 second paragraph replace "activity bit" with "activity flag" also on pg 5 etc. Author response: replaced. pg 5 second paragraph replace "hand-generated" with "hand-coded" Author response: replaced. pg 5 third paragraph: Do I understand that the "Dynamic" version is not purely dynamic in the sense that everything is made active but instead it runs on top of what the "Static" version has already figured out so in effect "Dynamic" is a hybrid? Could you make this clearer? Author response: Yes. In the interim, we have implemented a purely Dynamic version of OpenAD which acts exactly as the purely Dynamic version of ADIC: All double precision variables are of the active type, and their activity flags are initially set to active. This is now contrasted to the existing OpenAD which uses the MayActivity analysis and is labeled as hybrid1, and our new work with the MustMayActivity analysis, labeled as hybrid2. This gives us a baseline against which to compare our hybrid technique. pg 6 first paragraph: The last sentence alludes to the gains in the case of half the inputs being independent. I know space is tight but may be you find a way show all these results. Author response: Planning to include data on the 50% active independents. pg 6 second paragraph: double negation in "non-insignificant" how about "significant" or "noticeable" instead? Author response: used "noticeable". pg 6 second paragraph: "... cannot determine the activeness..." sounds to me like it is useless. Perhaps you can replace "Because this analysis....may be sub-optimal" with "In the generated derivative code this overestimate of the set of active variables ensures correctness but the code may be sub-optimal" Author response: Good suggestion. Replaced. pg 6 second paragraph last sentence. It is not clear to me why the static must analysis is forward direction only. Author response: The forward direction of static must analysis allows us to classify memory def/use locations of mayActive variables as either MayVaryMayUseful or MustVaryMayUseful. Our proposed hybrid approach looks to decrease the number of activity flag checks by statically determining the memory refences of the mayActive variables where we know they will be MustVary, It is at those memory references that we can exclude the activity check. The knowledge of MustUseful as opposed to MayUseful does not add any usable information for our hybrid approach. pg 7 last paragraph: " Currently, the hybrid accumulation routines involve multiple subroutine calls" Why is that? If you suspect that to be the source of the problem it sounds like something that could easily be fixed by code generation to get a fairer comparison. Author response: Still on our list of "to-do" items for further research. Also it might be useful to see what percentage of axpy operations require checking vs the ones that don't to get an idea how much of an impact the hybrid approach has on the generated code. Author response: Still on our list of "to-do" items for further research.