[Rivet] [Rivet-svn] r2394 - in trunk: include/Rivet src/Core src/Tools

[Frank Siegert]

Andy Buckley, Friday 09 April 2010:
> On 08/04/10 23:31, Frank Siegert wrote:
> > 1. The getParticleNamesMap() function in ParticleName.hh
> 
> This was on my private list for overhauling: it just went up several
> notches.

Yes, I have only mitigated the most important consequences, but you are
right, this needs some more overhauling.

> > 3. Now Log::getLog takes up 20% of analyze().
> > This is caused by the map searching, not any actual output. I haven't 
> > solved that yet, as that would probably involve some rewrite. Instead I've 
> > used a simple hack (prof_getlog.patch) to disable the log searching for 
> > further profiling. If anybody has a good idea here, please shout.
> > -> callgrind.out.3getlog
> 
> I think we should nick some nice logging macros from ATLAS to kill
> logging CPU time associated with messages below the current level. This
> will take some migration but can speed up a lot.

We have a very nice system for that in Sherpa, which should be very easy
to rip out, see ATOOLS/Org/Message.[HC]. This also includes some very
convenient macros. I could put this into Rivet, but I wouldn't want to
do the full migration of all output just by myself.

> > 4. The output of beam pairs to TRACE level in Event::_geNormAlignment 
> > takes up 15% now. I have removed it.
> > -> callgrind.out.4nooutputinalign
> 
> We could reinstate this with the logging macros for protection.

Yep.

> > 5. Now beam projection and sqrtS() are 20% of analyze().
> > I don't think we need to continuously monitor the event beams, but one 
> > initial check is enough. So I have removed that from the analyze() phase.
> > -> callgrind.out.5onlyinitialbeamcheck
> 
> Why are they so slow?! It's a super-simple projection, and sqrt(s) is
> arithmetic... in fact, it should be just one addition most of the time. Hmm.

Hmmm, interesting. Looking at the profile output more closely again, this
stems again from the beamIds DEBUG output! I'll put the beam check back in,
and instead temporarily disable that output, until our logging is
overhauled.
Interestingly this is closely related to the ParticleNames stuff above,
because it's the particle name output which is so expensive here.

> > I have committed the proposed fixes for 1, 2, 4 and 5. Would somebody be 
> > willing to look for a proper solution to 3?
> 
> I guess this is me. Macros are easy but need migration in the code. But
> since production runs tend to be ~silent, they would save all this CPU.
> Otherwise it's a logging system redesign: argh.

I'll definitely help as well. Maybe I can show you the Sherpa
implementation, and if you like it we can start out from that? Ping me
on Skype if you want to talk about it.

Frank