Software Coordinating Committee Conference Call January 3, 2002 1:00 PM EST Recorder: C. DeTar Present: Brower, DeTar, Mawhinney, Mendez, Holmgren, Watson (snowbound), Edwards (snowbound) Absent: Pochinski ** Action items 1. Still need help in getting together the Software Slides for the poster for the SciDAC PI meeting next week. Maybe create a single large poster - easy to do after the fact Mendez: svPablo graphics Robert: P4 Benchmarks for bar chart graphics Chris McLendon Holmgren: P4 data Watson: MP-API graphic ** Any other suggestions: 2. Vicky White and Robin Staffin from the DOE are visiting BU next Monday Jan 7 and MIT on Tuesday Jan 8. Specifically here are the questions Vicky sent to Brower: Brower; Vicky White and Robin Staffin want to know > discussion of participation - who, where; > discussion of problem areas - what, why; > and is there anything we can do to help. ** Give me your input. Especially helpful to me (if not in the meeting in an Email message) is an eplicit list of all supported SciDAC personnel and their assigned tasks. I want to make an accurate slide for Vicky's visit which I can defend. Not that she asks what we need to succeed. So if there are obvious unmeet needs I won't hesitate to pass this along. 3. Quarterly report at all hands meeting ** All to contribute 4. All hands Jlab meeting date Feb 1, Feb 2 Claudio Rebbi is organizing content of all hands mtg ** Brower: Try for software meeting Saturday afternoon and evening. 5. Performance tools Brower: What are tradeoffs between ease-of-use coding and more difficult, but optimized coding? Can we use performance tools to give programmer good advice? Can use Celso's svPablo? How much does it need to be changed? Celso: Can't see many changes required. Can add mirror library for function passing (same routines that incorporate profiling). Brower: Since MILC code has been used as a guinea pig for svPablo, perhaps what we need is documentation to show how it can be applied to QCD code. Celso: P4 not supported by PAPI - perhaps in a few months, it will. Brower: What abou QCDOC? Mawhinney: Simulator works at gate level, so gives all the information needed. But difficult to use. So community resource would be to provide optimized staggered and Wilson inverters as models for writing optimized code. Current performance: Staggered single processor 70% (Christian), Wilson 80% (Boyle). 6. Continuing saga level 2 design and data layout Edwards: Subsets of sites could be implemented via a copy with mask. Brower: Robert, Bob, and Carleton to work further on details. DeTar: We need to hear from rest of committee whether the general direction makes sense. Bob: Level 3 should operate on a predefined generic layout for the purpose of writing optimized QCDOC Level 3 code. Bob: The Level 3 routine would be required to do remapping of input and output to achieve compatibility with a Level 2 layout. Brower: Should we publish this generic layout as a default standard for Level 2? DeTar: What does publish mean? I would hope it means merely advising the QCDOC user to link with "layout_qcdoc.o" to avoid remapping overhead, but allowing the user to make any other choice of layout on a different platform. It shouldn't mean the user can make additional assumptions about where data is without breaking the Level 2 protocol. Robert: By agreeing to remap in going from Level 2 to Level 3 and back, we preserve the data parallel design and hide the layout details from the user. Next call Thursday, January 10, 3 PM EST Conference concluded at 3 PM EST. - ------- End of forwarded message ------- ------- End of forwarded message -------