Hi!

Bjarne Stroustrup was here at CERN many weeks ago. In my previous entry I promised to tell you what else we were discussing: threading, symbols and reflection.

I already mentioned how amazing his visit was in the previous entry; I also summarized our discussion on memory issues. You can still find the slides for all the topics in Indico.

Threading

Matevz Tadel gave an overview of HEP's issues with threading - the fact that we need to make use of the cores, and we can either use multi-process (but run into memory limits) or multi-thread. OpenMP and alike are not giving enough gain for reconstruction code; we're talking about event level parallelization instead. The support for threading will be part of C++0x (see e.g.

async()

), and there will be a special storage class for thread local data, see the proposals for Dynamic Initialization and Destruction with Concurrency and Thread-Local Storage. That's very good news but of course doesn't solve the underlying issue. Bjarne was happy to hear that we foresee issues with 32 cores - he said most other people in the committee did not believe that this would be relevant. So here, too, HEP would benefit from more influence in the C++ committee.

Symbols

Because our interpreters don't know what users will call we need information for any possible function. This destroys the whole beauty of templates: instead of only generating the code for those functions that are actually needed [1] we have to create all all symbols. We are probably talking about tens megabytes of duplicate code, because a

vector*>

is really just the same as a

vector*>

, in about 99.9% of all use cases. So it would be really nice if we could collapse them all into one, and just re-use its symbols: the constructors and all its other member functions like size, at, begin, const begin, end, const end, and so on. I got the impression that we are pretty much alone with this - but I also believe that it should be possible! If only we had more time to follow up with these things! If you want to save your experiment a few tens of megabytes of code then let me know :-)

Reflection

This is my main playground when it comes to C++, I'll try to keep it short nevertheless ;-) C++ is missing a way to identify what that object is that you want to store in a ROOT file: what's its type? What are its data members? Where are they in memory? That's called reflection and it's solved by our dictionaries. Still it would be really nice to have that in C++ itself: to be able to create objects given their

type_info

, to determine whether and how one object can be converted to another type, given the source and target

type_info

, and to enumerate the members that a type has, with their offsets and respective types.

The compilers have that data anyway! So "all we need" is a fast way to access it, an optional way that doesn't cost if it's not used. While we thought that this is a huge thing that would never make sense in the generic C++ context, Bjarne actually recommended we get this going. He said he's not aware of anyone having ever tried to extend

type_info

. And that we should come up with a proposal and submit it to the committee.

Of course that would be terrific, but now we have the usual issue that the committee is fighting with since its birth: we need to get the code working now, so there's simply no time left for fundamental improvements in C++. It would be so nice if we had a few more people in HEP that are allocated to these fundamental developments... Maybe Marc Paterno will be able to help us once C++0x is out the door! So why didn't I write for so long? Because I'm lazy and I thought it doesn't matter! :-) And why did I write now? Because a friend of mine told me that it doesn't work that way and I need to go on. OK, so here we go. And what's the plan for the next entry? There are a few fundamental (as in factor 6) speed improvements in the I/O: many of your (framework-less) analyses will now be blocked by your CPU speed and not by your disk speed anymore! Actually - before I talk about that I'll show our experience with Coverity's incredible static code checker which found, ehrm, a "few" bugs in ROOT, many of which got fixed right on time for the v5-26 release!

Talk to you soon!

Cheers