1. Code Migration James N. Bellinger University of Wisconsin at Madison 7 July 2010 1

2. 7.0.1.migrate vs 7.0.1.m We already validated 7.0.1.migrate on SL5 and SL4 against 7.0.1 built on SL3 Expect 7.0.1.m to be identical to 7.0.1.migrate On SL4 and SL5 (at Wisconsin), it isn’t – At.999999, no difference, but at -1: Emfilter/skim ClusterAna(ces strip:ces wire:cpr wire)*(avg adc:gain:occ) Invisible differences Not sure why there should be any differences at all – Cron job failed to update local db references? Executive summary: it looks the same at.999999 7 July 20102

3. CDF Librarians Tracked down a few dozen more missing names – Still about half the libraries missing a maintainer – Consider RootEventDisplay (just an example in the news) Management was handed off to Irena Shreyber some years ago – Her current supervisor is not interested in CDF and she doubts she’d be able to spend time on it if problems arose We can go back to Loginov (still a contributor) if he is willing, probably most knowledgeable Remember why we care – final code migration will use more stringent compilers, more errors to fix 7 July 20103

4. Optimize Code Speed Two fronts: – Validate maxopt, or find some optimization level we can validate Compilers: improving and introducing new bugs If we can validate existing release, no new release needed – Find if there’s some obvious resource hog: CMS got rid of CLHEP in tracking code in favor of faster Root matrix routines Implies a new release! First pass with google perftools: listed most CPU usage in nameless routines (address-only) 7 July 20104

5. CPU Profiling on 100 events (too few?) 7 July 20105 Tbranch::GetEntryopen in GLIBC No name, probably system library: Not very useful info