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

7.0.1.migrate vs m We already validated migrate on SL5 and SL4 against built on SL3 Expect m to be identical to migrate On SL4 and SL5 (at Wisconsin), it isn’t – At , 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 July 20102

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

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

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