Org-ad-workshop Februar 2006

org-ad-workshop@lists.rwth-aachen.de

8 Teilnehmer
23 Diskussionen

Moving Telco to 5pm my time on Wednesday

von Christian Bischof

Folks, there was consensus that Wednesday would work out well. However, I would like to move to 5pm my time. Is that possible for all of you? - Chris -- Prof. Christian Bischof, Ph.D. Institute for Scientific Computing and Center for Computing and Communications RWTH Aachen University Seffenter Weg 23, 52074 Aachen, Germany Tel. +49-241-8029110, Fax +49-241-8022241 bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>, www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>, www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>

18 Jahre, 3 Monate

Re: [Org-ad-workshop] Date(s) for final version

von Forth Dr Shaun

Jean, I've just emailed Paul backing your 13th decision. Sorry I didn't remember seeing your final mail to him with that decision so this morning thought we still had an issue to sort. Shaun ##################################################################### Dr Shaun Forth Applied Mathematics & Operational Research Engineering Systems Department Cranfield University, Shrivenham Campus Swindon SN6 8LA, England tel.: +44 (0)1793 785311 fax.: +44 (0)1793 784196 email: S.A.Forth(a)cranfield.ac.uk http://www.amorg.co.uk http://www.rmcs.cranfield.ac.uk/amor ##################################################################### >-----Original Message----- >From: org-ad-workshop-bounces(a)lists.rwth-aachen.de >[mailto:org-ad-workshop-bounces@lists.rwth-aachen.de] On >Behalf Of Jean Utke >Sent: Tuesday, February 07, 2006 3:12 PM >To: Christian Bischof >Cc: Organizers AD Workshop >Subject: Re: [Org-ad-workshop] Date(s) for final version > > >Shaun, Uwe, > >The only answer I got yesterday was the one from Chris (see below, I >think you got it too) which I took as the answer and >relayed last evening to Barbara and Paul. Today's deadline >looming made >me think I shouldn't wait any longer. >I.e. I think the 13th it is. I can do the review after that provided >you trust me with it and confirm with you >whatever I find per e-mail. I wish we didn't have this conundrum >because the 10th has long been >known to be the date. On the other hand I do want to make sure we get >the best possible version of >the paper and if the additional time makes it better then I am all for >the extension. Sorry for the confusion. >Lets blame on the 6 or 7 hours of time difference - unless you still >want to tar and feather me. :-) > >jean > > >Christian Bischof wrote: > >> Jean, I would not want to go later than Feb. 13, i.e. give them the >> weekend. I will also be at a meeting next week Mo-Thurs. >which limits >> my infrastructural possibilities some (but not totally :-)) - Chris >> >> Jean Utke wrote: >> >>>Hi, >>> >>>I briefly talked to Paul about this but since I hadn't seen a >>>problem postponing the due date to begin with I am not sure what >>>to tell him about delivering his revised version later. >>>Chris and Shaun, since you voted for sticking to the 7th as >I remember >>>can you please let me know what to tell Paul (or send him e-mail >>>directly)? >>> >>>Thanks, >>> >>>jean >>> >>>Jean Utke >>>Argonne National Lab./MCS >>>utke(a)mcs.anl.gov >>>phone: 630 252 4552 >>>cell: 630 363 5753 >>> >>>On Mon, 6 Feb 2006, Paul Hovland wrote: >>> >>> >>> >>>>Dear AD2006 organizers, >>>> >>>>Today we received reminders from Uwe that our revised papers are due >>>>tomorrow, Feb 7, and from the ICCS organizers that they are due Feb >>>>19. The original conditional acceptance letter we >received from Jean >>>>indicated that the deadline of Feb 7 was due to a Feb 10 >final deadline >>>>imposed by the ICCS organizers. Since the ICCS organizers appear to >>>>have pushed this final date back to the 19th, will the >AD2006 deadline >>>>be pushed back to Feb 16 (or, since 19 is a Sunday, perhaps Feb 15)? >>>>I'm not too worried about the Linearity paper with Michelle >(although >>>>given all of my other commitments, a few extra days there >wouldn't hurt >>>>either), but I'm a little worried about the Dynamic >Analysis paper with >>>>Barbara Kreaseck, especially since Michelle and I haven't >been able to >>>>devote much time to it. We will comply with the Feb 7 deadline if >>>>necessary, but 12 days for y'all to evaluate the revised >version does >>>>seem a tad excessive. >>>> >>>>Thanks for any clarification you can provide... >>>> >>>>Paul >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> -- >> >> Prof. Christian Bischof, Ph.D. >> >> Institute for Scientific Computing and Center for Computing and >> Communications >> >> RWTH Aachen University >> >> Seffenter Weg 23, 52074 Aachen, Germany >> >> Tel. +49-241-8029110, Fax +49-241-8022241 >> >> bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>, >> www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>, >> www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/> >> > > >-- >Jean Utke >Argonne National Lab./MCS >utke(a)mcs.anl.gov >phone: 630 252 4552 >cell: 630 363 5753 > > >_______________________________________________ >Org-ad-workshop mailing list >Org-ad-workshop(a)lists.rwth-aachen.de >http://mailman.rwth-aachen.de/mailman/listinfo/org-ad-workshop > > -- This message has been scanned for viruses and dangerous content by the Cranfield MailScanner, and is believed to be clean.

18 Jahre, 3 Monate

Re: [Org-ad-workshop] Date(s) for final version

von Forth Dr Shaun

Dear Paul, DEFINITIVE REPLY Sorry for the confusion arising from the Atlantic time difference. Jean has already indicated to you he is happy to go with the 13th - so we'll go with that. Unfortunately I didn't see the email where Jean made the decision - hence my rapid action this morning with the deadline looming. He's obviously more generous that me! Jean is obviously aware of your progress so hopefully we can have a productive meeting tomorrow. Shaun > Can I just point out that we gave you notification of >acceptance on or about 23rd January, at least a week ahead of >the "official notification" you received direct from the >organisers. The paper rejection rate for the conference was I >think something like 60-70%. In many workshops and the main >track this can only have been achieved by pretty harsh >rejection criteria. We have tried to be a little more >generous in order to keep the workshop alive, less than 8 >papers and it would have been killed, but this does mean we >have to spend a little longer checking the revised papers than >we should have done. The organisers were always going to have >been struggling with the original 7th receive and 10th accept >deadline. Since we didn't know about the extension to the >19th until we'd sent out our acceptance then we decided to >keep the 7th as it was with the view that this would give us >time to clear up problems with any of the authors who were >struggling to get the corrections done! > >We do not want to be unreasonable. I've already checked with >Uwe and, provided Chris or Jean don't object, perhaps you >could make a considered review of the referee's comments for >the Kreaseck paper and report back to us by Weds 8th 14:00 >GMT, via Jean if you need to talk, with progress to date and >an assurance that you are able to address all issues. We are >having a review meeting for the revised papers later that >afternoon. If you would then send the fully revised version on >to us by Monday 13th then we can get back to you with any hopefully minor >(e.g. formatting) issues on the 14th/15th. > >I hope this answers the questions you raised and gives you the >time to make the changes requested. > >Regards > >Shaun > >##################################################################### > Dr Shaun Forth > Applied Mathematics & Operational Research > Engineering Systems Department > Cranfield University, Shrivenham Campus > Swindon SN6 8LA, England > tel.: +44 (0)1793 785311 > fax.: +44 (0)1793 784196 > email: S.A.Forth(a)cranfield.ac.uk > http://www.amorg.co.uk > http://www.rmcs.cranfield.ac.uk/amor >##################################################################### > > >>-----Original Message----- >>From: Paul Hovland [mailto:hovland@mcs.anl.gov] >>Sent: Monday, February 06, 2006 4:15 PM >>To: Uwe Naumann; Christian Bischof; Jean Utke; Forth Dr Shaun >>Cc: Paul Hovland >>Subject: Date(s) for final version >> >> >>Dear AD2006 organizers, >> >>Today we received reminders from Uwe that our revised papers are due >>tomorrow, Feb 7, and from the ICCS organizers that they are due Feb >>19. The original conditional acceptance letter we received >from Jean >>indicated that the deadline of Feb 7 was due to a Feb 10 final >>deadline >>imposed by the ICCS organizers. Since the ICCS organizers appear to >>have pushed this final date back to the 19th, will the AD2006 >deadline >>be pushed back to Feb 16 (or, since 19 is a Sunday, perhaps Feb 15)? >>I'm not too worried about the Linearity paper with Michelle (although >>given all of my other commitments, a few extra days there >>wouldn't hurt >>either), but I'm a little worried about the Dynamic Analysis >>paper with >>Barbara Kreaseck, especially since Michelle and I haven't >been able to >>devote much time to it. We will comply with the Feb 7 deadline if >>necessary, but 12 days for y'all to evaluate the revised version does >>seem a tad excessive. >> >>Thanks for any clarification you can provide... >> >>Paul >> > -- This message has been scanned for viruses and dangerous content by the Cranfield MailScanner, and is believed to be clean.

18 Jahre, 3 Monate

Re: [Org-ad-workshop] Date(s) for final version

von Christian Bischof

Jean, I would not want to go later than Feb. 13, i.e. give them the weekend. I will also be at a meeting next week Mo-Thurs. which limits my infrastructural possibilities some (but not totally :-)) - Chris Jean Utke wrote: >Hi, > >I briefly talked to Paul about this but since I hadn't seen a >problem postponing the due date to begin with I am not sure what >to tell him about delivering his revised version later. >Chris and Shaun, since you voted for sticking to the 7th as I remember >can you please let me know what to tell Paul (or send him e-mail >directly)? > >Thanks, > >jean > >Jean Utke >Argonne National Lab./MCS >utke(a)mcs.anl.gov >phone: 630 252 4552 >cell: 630 363 5753 > >On Mon, 6 Feb 2006, Paul Hovland wrote: > > > >>Dear AD2006 organizers, >> >>Today we received reminders from Uwe that our revised papers are due >>tomorrow, Feb 7, and from the ICCS organizers that they are due Feb >>19. The original conditional acceptance letter we received from Jean >>indicated that the deadline of Feb 7 was due to a Feb 10 final deadline >>imposed by the ICCS organizers. Since the ICCS organizers appear to >>have pushed this final date back to the 19th, will the AD2006 deadline >>be pushed back to Feb 16 (or, since 19 is a Sunday, perhaps Feb 15)? >>I'm not too worried about the Linearity paper with Michelle (although >>given all of my other commitments, a few extra days there wouldn't hurt >>either), but I'm a little worried about the Dynamic Analysis paper with >>Barbara Kreaseck, especially since Michelle and I haven't been able to >>devote much time to it. We will comply with the Feb 7 deadline if >>necessary, but 12 days for y'all to evaluate the revised version does >>seem a tad excessive. >> >>Thanks for any clarification you can provide... >> >>Paul >> >> >> >> > > > > -- Prof. Christian Bischof, Ph.D. Institute for Scientific Computing and Center for Computing and Communications RWTH Aachen University Seffenter Weg 23, 52074 Aachen, Germany Tel. +49-241-8029110, Fax +49-241-8022241 bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>, www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>, www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>

18 Jahre, 3 Monate

Re: [Org-ad-workshop] [Fwd: [ICCS 2006] Review results]

von Jean Utke

Hi Barbara, I briefly discussed this with Paul this morning. I sent an e-mail to hear from the other members of the organizing committee since some of us definitly wanted to keep the 7th despite the last minute surprise extension given by the conference. I will let you know as soon as I get feedback. Jean Barbara Kreaseck wrote: >Hi Jean, > >This announcement from ICCS 2006, contains the deadline of >February 19 for the final version of the paper. I understand >that this extends the deadline from February 10 to February 19. > >What impact does this new deadline have upon the workshop >deadline of February 7 (tomorrow)? Can we have until February >16, instead? > >Thanks. > >-- Barbara > >---------------------- Original Message ----------------------- >Subject: [ICCS 2006] Review results >From: "ICCS 2006 Org. Com." <dick(a)science.uva.nl> >Date: Sat, February 4, 2006 4:31 am >To: "B. Kreaseck" <bkreasec(a)lasierra.edu> >--------------------------------------------------------------- > >Dear B. Kreaseck: > >This e-mail concerns your paper submission entitled Hybrid >Static/Dynamic >Activity Analysis for one of the workshops in ICCS 2006. We >would like to >thank you for your contribution to the ICCS 2006 conference. >After an >extensive review we are happy to announce that your paper has >been accepted >for publication and for ORAL PRESENTATION (20 minutes) at the >ICCS 2006 >conference in Reading (UK) > >Comments by the reviewers of your paper can be found on the >following specific >web page: >http://www.iccs-meeting.org/iccs2006/papers/paper.php?authid=884P447BD6FBBE… >This acceptance is CONDITIONAL in the sense that BEFORE >February 19 we need: >- your paper of no more than 8 camera-ready pages, taking into >account the >remarks by the reviewers and formatted STRICTLY ADHERING to the >LNCS format >rules. > The guidelines for submitting the camera-ready paper can be >found on the >following web page: > http://www.springer.com/sgw/cda/frontpage/0,11855,5-164-2-72376-0,00.html, >- your copyright transfer form, >- your registration for the conference before March 10! > >Please, note that exceeding the 8 page limit will result in you >paper being >dropped from the proceedings. > >Please, precisely follow the LNCS rules and upload the final >camera-ready >version in POSTSCRIPT or PDF. Also upload the complete sources. >(MS Word doc >files, or tex with all figures and styles. The latter >preferably in a zip or >zipped tar file.) >Remember that at least one of the co-authors of each paper must >register for >the conference and present the paper in order for the paper to >be included in >the Proceedings. > >Your copyright transfer should be faxed to Fax: + 44 118 378 >5224; for the >form see the Spinger site above. > >For your registration form and information on the registration >fee, see: >http://www.iccs-meeting.org/iccs2006/ >Registration information will be available from Monday, >February 6 onwards. > >Thank you for your work and interest in ICCS. Please, do not >hesitate to >contact us with any questions that you may have. > >Please, note that travel to Reading may require you to start >arranging things >NOW (visa, airline seat reservations, etc.). >Information about obtaining invitation letters for visa can be >found on the >ICCS 2006 website. > >Thanks again for your contribution to ICCS 2006 conference. > > >Scientific Organizing Committee >ICCS 2006 > > > > -- Jean Utke Argonne National Lab./MCS utke(a)mcs.anl.gov phone: 630 252 4552 cell: 630 363 5753

18 Jahre, 3 Monate

[Fwd: [ICCS 2006] e-mails sent] - next Telco

von Christian Bischof

Folks, Info from the organizers concerning notification of authors below. I just sent out a reminder for the three accepted papers that I am responsible for (to Shaun, Ralf Giering, J. Kim@MCS) to remind them of the fact that papers were due on Feb. 7. I also had two slots for a telco scheduled, 4.30pm on Tue and 4pm on Wed. In light of the moved deadline, I suggest that we do a TelCo on Wed. 4pm my time. Would that suit all of you? Best regards, Chris -------- Original Message -------- Subject: [ICCS 2006] e-mails sent Date: Sat, 04 Feb 2006 15:04:13 +0100 From: ICCS 2006 Org. Com. <dick(a)science.uva.nl> Reply-To: dick(a)science.uva.nl To: bischof(a)sc.rwth-aachen.de, "C. Bischof" <bischof(a)sc.rwth-aachen.de> Dear C. Bischof, Barring mistakes, your authors should now have received the e-mails giving them the review outcome. Kind regards, Dick van Albada -- Prof. Christian Bischof, Ph.D. Institute for Scientific Computing and Center for Computing and Communications RWTH Aachen University Seffenter Weg 23, 52074 Aachen, Germany Tel. +49-241-8029110, Fax +49-241-8022241 bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>, www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>, www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/>

18 Jahre, 3 Monate

Revised version of paper Dauvergne/Hascoet ICCS 2006

von Laurent Hascoet

Please find attached: -- The revised version of our ICCS 2006 paper as a tar.gz file with the latex source, 2 postscript figures and a .bib bibliography -- The concatenation of the three referees reports, with our replies inserted inside. The paper suggests a formal approach to characterize checkpointing sets vs taping. Both the application to programs that do not exhibit a special looping structure as well as the characterization of minimal solutions are new. It is a very usefull foray into using data flow for determining checkpointing sets and should definitly be accepted. The issues mentioned below should improve readability for the general audience. major comments: A: I realize notation regarding the result of the source transformation of program subsections in terms of forward and reverse is difficult because it does not lend itself easily to checkpointing schemes. E.g. on pg.3 Sect.3 states: $\overline{C}\Doteq\overrightarrow{C};\overleftarrow{C}$ and in this notation there is no mentioning of taking the checkpoint, running forward and later restoring the checkpoint although this certainly belongs to the source transformation of code section $C$ which is presumably what is denoted by $\overline{C}$ if one goes by the explanation of $P$ and $\overline{P}$ on page 2. Then on the top of page 4 there is a different notation that does includes the store/restore etc. >> Right. I added notation [] to denote checkpointing. >> \overline{C;D} is thus >> \overrightarrow{C};\overrightarrow{D};\overleftarrow{D};\overleftarrow{C} >> whereas \overline{[C];D} is the reverse diff program with C checkpointed >> with the store, restore, etc. However, on page 4 I am missing an explanation of the notation "\hbox{\it Req} \vdash" which is repeatedly used as something being executed while "Req" itself is a set. The notation should be clarified. >> Req is not a piece of code. It is a context in which >> the code generation is done. When using rewrite rules, >> people use \vdash to mean this. >> Yes the rewrite rules here are ambiguous. >> I put a box around to distinguish the rewrite terms >> plus one line of explanation. B: I don't see a clear motivation for the backward snapshot as opposed to the tape. In the paper just states it is a "hybrid". The need for the regular checkpoints is clear. >> Backward snapshot does not save memory space, >> but may reduce memory traffic (e.g only one >> push/pop pair instead of 2. Added this on page 4. Sect 4. mentions that there can be a trade-off between storing/restoring things in big blocks vs. doing it one at a time. This would presumably be the implied motivation for the backward snapshots. It would be nice if the conclusions section could address this by showing more detail about profile data for taping push/pops vs. storing/restoring snapshots. >> Our first measurements on memory traffic are too recent, >> and not conclusive yet. C: I missed any mentioning of checkpoint placement as an issue. The space constraints don't allow to go into much detail. However, it should be pointed out that (aside from special cases such as time stepping loops) the segmentation of the code into the subsections U,C,D which in this paper is predetermined can have a substantial impact on the checkpoint size. >> I took your words to rephrase the end of the conclusion, >> which meant that. minor comments: pg 2: If there isn't a special purpose for calling the three parts upstream/center/downstream, could they be renamed A/B/C instead? >> I sort of like using U for Upstream, C for Checkpoint, D for Downstream ? pg 2: Can you cite the TBR paper at the first mentioning of TBR analysis . >> Done pg 2: change "... finds the Req set of these required values." to "...finds the set of these required values denoted by Req." >> ok May be there is a chance to also actually say what precisely "out()" and "use()" mean, in particular if it is 'local use' only of cumulative with the 'use' of a segments 'callees'. To the uninitiated reader it is probably not clear enough from the context. >> added a few words on bottom of page 4 pg 2: the sentence "In other words ... must be built in such a way that:" with the following formula should either be removed or better explained. The assertion "must be built" wrt. the formula becomes clear only after reading on and going back later. >> Good. We gain 3 lines! pg 3: I think the sentence "This also uses memory space, although less than the tape for ..." should really relate to the *placement* of the checkpoints, i.e. the segmentation of the program. That is crucial and should be mentioned to better motivate above sentence and the initial trade-off between taping and checkpointing space. >> agreed. pg 5: in the condition for "\it Snp" (3rd last line), it is not immediately apparent to me where the \cup (\hbox{\it Req} \setminus \hbox{\it Sbk} comes from. I suspect this is just my mistake but without that last bit it appears to be directly derived from eqn. (3). With it the intersection on the right hand side may be larger than without which makes me wonder about the "necessary and sufficient"? Since I have a similar problem with the Req_D eqn. I am just guessing I am missing some step but you may want to consider adding this. >> This is because Snp also appears in >> equation (4). Equation (3) alone does imply that >> Snp >= (out(C) \cup (out(Db) \ ReqD)) \cap use(Cb) >> in addition (4) implies that >> Snp >= (out(C) \cup (out(Db) \ ReqD)) \cap (Req \ Sbk) >> same happens for ReqD. >> We do think the conditions are necessary and sufficient. pg 6: In the solution of the set equations - what is the optimality criterion? The text mentions "minimal" and "optimal" solutions. Naively looking at the equations in (6) it seems Opt_2^- is the only part occurring twice so any partition that leaves Opt_2^- empty seems to be better in terms of the total size of Sbk, Snp, Req_D, Req_C ? So I suspect total memory footprint isn't the criterion. >> Right. I added that these sets are minimal in the sense that any >> semantics-preserving choice of the 4 sets is >> larger or equal to one of these minimal quadruplets. pg 8: Please clarify "... choices of the other checkpoints around." What is around? It could be that once the notation issue raised under the major issue "A" is addressed this may well become clear. >> Rephrased. -------------------------------------------------------------- [Overview] More explanation on notation is needed. >> added explanations on the \overline notation >> and the rewrite rule on page 4 >> However, we will also have to spare half a page, >> so sometimes we have to rely on commonly >> used notation. [Comments] page 2, line -8 (8 from the bottom) The term "out" is not defined here. >> removed and explained on next occurrence page 4 page 3, line 11 The meaning of the semicolon in the notation $\overline{D}\Doteq\overrightarrow{D};\overleftarrow{D}$ should be explained. >> done. This use of semicolon for code sequence is widespread. page 3, Figure 2 The term "Sbk" is not defined here. >> Right, but it is defined upon its first occurrence in the text page 4, line 3 The notation "$Req\vdash \overline{C;D}$" was hard to be understood because PUSH(Sbk) is undefined here. page 5, line 15 ( eq.(3)) The reason of disappearance of "PUSH(Sbk)" in (1) should be explained. >> done. A PUSH does not overwrite any program variable. -------------------------------------------- 1. Introduction You write: ... it (reverse mode AD) suffers from a high memory consumption... That is only true for the store all or store minimal strategy implemented in Tapenade, ADIFOR 3, and OpenAD. If every intermediate result is recomputed then reverse mode AD needs little memory but suffers from computational costs! You might want to read and cite other papers about AD. You write: This memory consumption is inherent to the nature of gradient computation. That is obviously wrong. You write: to solve the adjoint equations ... is also known to consume memory space. What you mean by this. Almost every computation requires memory (it doesn't consume it like eating bred). AD generated code also solves the adjoint equation! The first two paragraphs in the introduction need to be rewritten totally. >> Rewritten as: >> The methods to compute gradients can be classified in two categories. >> In the first category, methods use CPU more intensively because >> several operations are duplicated. This can be through >> repeated tangent directional derivatives, or through reverse >> Automatic Differentation using the ``Recompute-All'' strategy. >> This is not the context of this paper. In the second category, >> methods spare duplicated operations through increased memory use. >> This encompasses hand-coded resolution of the ``adjoint equations'' >> and reverse Automatic Differentation using the ``Store-All'' strategy, >> which is the context of this work. 2. Reverse Automatic Differentiation You write: AD is a program transformation technique. ... an AD tool creates a new program ... no, see tools based on operator overloading >> ok. Text modified. TBR = to be recorded not to be restored >> Right. Fixed. What is the definition of 'Req'? >> Explained in section 2. Rephrased. What is the difference between Req and use(U)? >> In the paper we define Req as use(\overleftarrow{U}), >> which is smaller than use(U) as said in section 2 and >> detailed in refs [2,6] What is the definition of OUT? I guess what you name OUT is actually termed KILL in data flow analysis. >> Defined now page 4. KILL usually denotes scalar and array >> variables completely overwritten. OUT is for variables even >> only partly overwritten. 3. The equation of checkpointing snapshots You write: This allows the tape consumed ... to be freed ... That is also true without checkpointing. The tape consumed by C is relevant here, it is needed after adjoint of D has finished. >> Both what you write and what we wrote is true, >> and both lead to the conclusion stated by >> the sentence that follows. What is Sbk? >> Defined in detail on its first occurrence in the text, page 4. >> True it appears on figure 2 before, but it is just a >> support for the discussion on page 4. You write: This also uses memory space, although less than the tape for C. That is not always true. >> Ok, but one can almost always write pathological examples >> for any such assumption. In real life, the snapshot is really >> smaller. It's an interesting question to detect those "C"'s >> for which snapshots are larger than the tape, but >> it's not in the scope of this paper. 4 Discussion and Experimental results Table 1: What run-time is shown, the function or the adjoint? One needs to see the run-time of function, eager adjoint, and lazy adjoint. What is the memory usage and run-time without checkpointing? >> added run-time of function. >> Run-times with eager and lazy do not differ significantly. >> Most examples would simply run out of memory if no >> checkpointing was made. 5 Conclusions I am missing an discussion of the computational cost of checkpointing, i.e. the additional flops and the cost of writing and reading the tape. The central question is what is the best mixture of recomputations and taping, not memory usage alone. >> Certainly a very general and important question. >> This paper does not claim to answer this question. >> But it gives an element to understand it better.

18 Jahre, 3 Monate

ICCS 2006 - Revised paper

von Andreas Kowarz

Dear organizers, as requested I send the revised version of our paper and the commented reviews with this email (please see the attachments). I have also submitted the new version (PS and TGZ) via the web interface. Regards, Andreas Kowarz -- ********************************************************************* Attention: My email address "kowarz(a)math.tu-dresden.de" is subject to removal within the next few month. Please use my new address "Andreas.Kowarz(a)tu-dresden.de" in order to contact me per mail. Please update your address book. Thanks. ********************************************************************* major comments: A: related to pg 5 first paragraph etc: The condition for retaping is stated only to be a change of control flow. ... Since a lot of this paper is about the nested taping it think it should undertake the effort to precisely characterize when a tape representative for a time step is valid, which invalidating scenarios are automatically caught and which extra steps are required. Comment: Now, we explain that the function evaluation is retaped automatically when the control flow changes due to a change of an adouble value. Furthermore, now we provide a flag such that if this flag is set to 1 the function evaluation is retaped for each reverse differentiation to be on the save side. A corresponding explanation is contained in the revised version of the paper. B: related to the numerical example in Sect 3. I would find it much more compelling if the paper gave more detail on the practical example ... The paper would gain significantly if this effect could be shown in a practically relevant application. Comment: We skipped the trajectory example and present now only the robotor example in detail. minor comments: pg 2, first paragraph: The statement of "enormous memory reduction" should be qualified. I.e. it should be stated that - presumably - it is compared to the tape (I guess more precisely execution trace and value tape) arising from purely split mode. Comment: done pg 2, insert: "The size of the much smaller randomly accessed ...." ^^^^^^^^^^^ Comment: done pg 2 last paragraph first sentence: The memory grows with run-time, regardless if this is a time-stepping procedure or not and what is acceptable depends on the user. I suggest to refer directly to the new nested tape facility in ADOL-C and point out that time-stepping procedures usually imply repetitions of identical operation sequences on the tape which the nested taping eliminates as explained on the bottom of page 3. Comment: We reformulated this sentence pg 4 end of first paragraph insert: "... presented at the AD 2004 conference." ^^^^^^^^^^ Comment: done pg 5 Interface section: The time_step_function signature requires the user to pack and unpack the state data that might be distributed over various arrays into u. I am not sure that everybody agrees this is "minimal user effort". Instead it might be fairer to say that the objective is a "lean and concise interface" which I believe has been achieved. Comment: reformulated correspondingly The following is more of a general comment. As ADOL-C wants to attract not only C but also C++ codes it should consider providing actual C++ interfaces along with the old C style ones. Serious C++ users of ADOL-C will likely cringe at the sight of the CpInfos* to be populated and a bunch of C functions when all of this perfectly lends itself to a well organized class. Comment: We added a C++ interface and changed the description correspondingly. p. 3 Fig 1, Fig 2: The light grey rectangle used in the new tape generation should be explained. What is the difference w.r.t the original ones ? Comment: A description of this light grey rectangle is contained in the text. What is the semantic of the arrows ? If you manage to show graphically the different tapes it would enforce the paper. Comment: The figures were rearranged and are hopefully easier to understand now. p. 4: You talk about the "external diff. function", but give no explanation nor a pointer to the paper at AD2004. Comment: This was presented in the poster session. We plan to have a documentation of this "external diff. function" facility in the ADOL-C manual within the near future. p. 5: You should give a code or a function example to clarify the user intervention. Explain the difference with a manual use of resolve from the user point of view. Comment: From out point of view, there is no space for such an explanation when the page limit is set to 8. Once more, we plan to have a corresponding documentation in the ADOL-C manual within the near future. Typos: p. 1 section 1: you use e.g sometimes in an unapropriate way. Comment: Well, we tried to fix as many as possible p. 7: "despite the fact of the" should be changed. Comment: done Experiments are made on a very small academic example. The results are quite convincing. I'm looking forward to results on real-life codes. Comment: We switched from the academic example to the roboter example Table 1 is puzzling. It actually looks like a simple affine function: tape-size = 492 + l*252. From which I deduce that it shows the memory consumption without any checkpointing? If there was some sort of optimal checkpointing, size should grow like log(l), right? Then why not show a table that shows that, which would better illustrate the benefits of checkpointing? Comment: In the old version, the Table shows the tape-size without any checkpointing. The tape size itself is constant if the checkpointing is use within ADOL-C. Only the amout of memory needed to store the checkpoints grows. The table now shows the tape size needed without and with checkpointing. Minor stuff: --The "applied checkpointing procedure" sounds bizarre cause it makes me wonder what is "applied checkpointing". Comment: Reformulated. --I was told that "allowing the usage..." is incorrect, should be "allowing us to use...", or "permits the usage..." Comment: Reformulated.

18 Jahre, 3 Monate

Re: [Org-ad-workshop] [Fwd: [ICCS 2006] e-mails sent] - next Telco

von Forth Dr Shaun

Wed 4pm German (=3pm GMT) OK for me. Shaun ##################################################################### Dr Shaun Forth Applied Mathematics & Operational Research Engineering Systems Department Cranfield University, Shrivenham Campus Swindon SN6 8LA, England tel.: +44 (0)1793 785311 fax.: +44 (0)1793 784196 email: S.A.Forth(a)cranfield.ac.uk http://www.amorg.co.uk <http://www.amorg.co.uk/> http://www.rmcs.cranfield.ac.uk/amor ##################################################################### -----Original Message----- From: org-ad-workshop-bounces(a)lists.rwth-aachen.de [mailto:org-ad-workshop-bounces@lists.rwth-aachen.de] On Behalf Of Christian Bischof Sent: Sunday, February 05, 2006 11:21 AM To: Organizers AD Workshop Subject: [Org-ad-workshop] [Fwd: [ICCS 2006] e-mails sent] - next Telco Folks, Info from the organizers concerning notification of authors below. I just sent out a reminder for the three accepted papers that I am responsible for (to Shaun, Ralf Giering, J. Kim@MCS) to remind them of the fact that papers were due on Feb. 7. I also had two slots for a telco scheduled, 4.30pm on Tue and 4pm on Wed. In light of the moved deadline, I suggest that we do a TelCo on Wed. 4pm my time. Would that suit all of you? Best regards, Chris -------- Original Message -------- Subject: [ICCS 2006] e-mails sent Date: Sat, 04 Feb 2006 15:04:13 +0100 From: ICCS 2006 Org. Com. <dick(a)science.uva.nl> <mailto:dick@science.uva.nl> Reply-To: dick(a)science.uva.nl To: bischof(a)sc.rwth-aachen.de, "C. Bischof" <bischof(a)sc.rwth-aachen.de> <mailto:bischof@sc.rwth-aachen.de> Dear C. Bischof, Barring mistakes, your authors should now have received the e-mails giving them the review outcome. Kind regards, Dick van Albada -- Prof. Christian Bischof, Ph.D. Institute for Scientific Computing and Center for Computing and Communications RWTH Aachen University Seffenter Weg 23, 52074 Aachen, Germany Tel. +49-241-8029110, Fax +49-241-8022241 bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de> , www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/> , www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/> -- This message has been scanned for viruses and dangerous content by the Cranfield MailScanner, and is believed to be clean.

18 Jahre, 3 Monate

Re: [Org-ad-workshop] [Fwd: [ICCS 2006] e-mails sent] - next Telco

von Uwe Naumann

Works for me. Uwe Naumann Software & Tools for Computational Engineering RWTH Aachen http://www.stce.rwth-aachen.de Folks, Info from the organizers concerning notification of authors below. I just sent out a reminder for the three accepted papers that I am responsible for (to Shaun, Ralf Giering, J. Kim@MCS) to remind them of the fact that papers were due on Feb. 7. I also had two slots for a telco scheduled, 4.30pm on Tue and 4pm on Wed. In light of the moved deadline, I suggest that we do a TelCo on Wed. 4pm my time. Would that suit all of you? Best regards, Chris -------- Original Message -------- Subject: [ICCS 2006] e-mails sent Date: Sat, 04 Feb 2006 15:04:13 +0100 From: ICCS 2006 Org. Com. <dick(a)science.uva.nl> Reply-To: dick(a)science.uva.nl To: bischof(a)sc.rwth-aachen.de, "C. Bischof" <bischof(a)sc.rwth-aachen.de> Dear C. Bischof, Barring mistakes, your authors should now have received the e-mails giving them the review outcome. Kind regards, Dick van Albada -- Prof. Christian Bischof, Ph.D. Institute for Scientific Computing and Center for Computing and Communications RWTH Aachen University Seffenter Weg 23, 52074 Aachen, Germany Tel. +49-241-8029110, Fax +49-241-8022241 bischof(a)rz.rwth-aachen.de <mailto:bischof@rz.rwth-aachen.de>, www.sc.rwth-aachen.de <http://www.sc.rwth-aachen.de/>, www.rz.rwth-aachen.de <http://www.rz.rwth-aachen.de/> _______________________________________________ Org-ad-workshop mailing list Org-ad-workshop(a)lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/org-ad-workshop

18 Jahre, 3 Monate

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Org-ad-workshop Februar 2006