Name: Anonymous 2009-12-10 10:13
Hi!
Bjarne Stroustrup was here at CERN last week. He gave a public presentation on the design of C++0x. We also invited him for a technical discussion of the issues we run into with C++, with a restricted audience. In this edition I'll give a summary of the latter: an intense, fruitful meeting with lots of interesting insights - as Bjarne Stroustrup claims on both sides :-)
It was a real pleasure to talk to Bjarne Stroustrup: even though (I'd say) he is one of the most influential persons in modern high performance computing he is very approachable; he listens to mere earthlings like us; he gives answers that are amazingly well thought though; and he even dares to state that he cannot give an answer or come up with an opinion when he has not enough experience on a topic.
I believe the biggest impact he had here at CERN was to encourage us to get involved: to contact our national representatives, to tell them what we want, and to think about sending a CERN representative to the C++ committee. And to not assume that our ideas and solutions are bogus just because we're not C++ specialists: he gave us the impression that many of our ideas make a lot of sense, enough sense to be suggested and discussed in the committee. But that it will be our job to make that happen. I would have never expected his visit to be so motivating and informative!
Back to our meetings: the public presentation was recorded, you can see the slides and hear his comments. He is one of those speakers where the slides only make up a tiny part of his presentation, so make sure to actually listen to him! Especially when you encounter Mars...
We came up with a list of topics to discuss in the technical meeting, which was converted into a set of four tiny presentations. I will post them on the indico page once I have write access to it :-) Bjarne Stroustrup requested that the presentations are cleared from HEP jargon so he can send them to the C++ committee. We might thus change them slightly in the near future.
The meeting was only advertised to a restricted audience, to not flood the room. A fair amount of people were interested, and as a matter of fact they were very interested: Bjarne Stroustrup seems to combine all the lack of luck into one day a year, and that was that day, resulting in a delay of about 45 minutes... For any other meeting I have been to people would have left, protested loudly, canceled the project, whatever - but here the audience was actually steadily growing! We also broadcast the discussion on EVO where a few people joined in and listened. Alas, no recording of the discussion exists, so I decided to summarize it here.
We got most feedback on the items memory management, threading, symbols, and reflection. Well OK, so basically on all items we wanted to discuss :-) I'll go through them one by one:
Memory Management
Rene Brun brought up the question of how to implement arenas (aka pools in the FORTRAN times) in C++. Ideally one would have a memory arena that stays for the whole process (e.g. magnetic field etc), and one that contains the event data and that gets flushed after every event, without worrying about leaks or destructors.
The major difference between C++ and FORTRAN and also the major problem is C++'s support of pointers: an object can be allocated in the proper arena (e.g. using new with placement), but how do you tell the object to put whatever it allocated into the same arena?
C++ 0x offers scoped allocators which can help. One can pass such an allocator around, allowing to create an object and all its owned objects (I assume that's what the scoped stands for) to be allocated in a certain way, e.g. in a certain arena. No need for templates, but the sub-objects must be smart enough to actually make use the allocator, i.e. it only works for hand-crafted classes. Which should be fine for the experiments' EDM.
The remaining issue is how to reduce the memory fragmentation for long-lasting arenas where parts get deleted and holes are created: to move pointers around one would need another level of indirection. Bjarne Stroustrup told us that there is a development towards "pointers' values are not memory addresses", i.e. an abstraction in the runtime or the OS, allowing a memory page to be moved if there is a free page between two allocated ones, and thus reducing the fragmentation.
Another way of C++ 0x to help with memory management is its optional garbage collection. Well, would have been garbage collection. A few strong voices lobbied so much against garbage collection that in the end only a garbage collection ABI will be part of the (current snapshot of the) standard; the actual implementation can be provided by libraries or the compilers, but there is no guaranteed, standard implementation.
I hope to be welcome you again for the next edition, where I will give the summary of the other points we discussed: threading, symbols, and reflection.
Cheers,
Axel
Bjarne Stroustrup was here at CERN last week. He gave a public presentation on the design of C++0x. We also invited him for a technical discussion of the issues we run into with C++, with a restricted audience. In this edition I'll give a summary of the latter: an intense, fruitful meeting with lots of interesting insights - as Bjarne Stroustrup claims on both sides :-)
It was a real pleasure to talk to Bjarne Stroustrup: even though (I'd say) he is one of the most influential persons in modern high performance computing he is very approachable; he listens to mere earthlings like us; he gives answers that are amazingly well thought though; and he even dares to state that he cannot give an answer or come up with an opinion when he has not enough experience on a topic.
I believe the biggest impact he had here at CERN was to encourage us to get involved: to contact our national representatives, to tell them what we want, and to think about sending a CERN representative to the C++ committee. And to not assume that our ideas and solutions are bogus just because we're not C++ specialists: he gave us the impression that many of our ideas make a lot of sense, enough sense to be suggested and discussed in the committee. But that it will be our job to make that happen. I would have never expected his visit to be so motivating and informative!
Back to our meetings: the public presentation was recorded, you can see the slides and hear his comments. He is one of those speakers where the slides only make up a tiny part of his presentation, so make sure to actually listen to him! Especially when you encounter Mars...
We came up with a list of topics to discuss in the technical meeting, which was converted into a set of four tiny presentations. I will post them on the indico page once I have write access to it :-) Bjarne Stroustrup requested that the presentations are cleared from HEP jargon so he can send them to the C++ committee. We might thus change them slightly in the near future.
The meeting was only advertised to a restricted audience, to not flood the room. A fair amount of people were interested, and as a matter of fact they were very interested: Bjarne Stroustrup seems to combine all the lack of luck into one day a year, and that was that day, resulting in a delay of about 45 minutes... For any other meeting I have been to people would have left, protested loudly, canceled the project, whatever - but here the audience was actually steadily growing! We also broadcast the discussion on EVO where a few people joined in and listened. Alas, no recording of the discussion exists, so I decided to summarize it here.
We got most feedback on the items memory management, threading, symbols, and reflection. Well OK, so basically on all items we wanted to discuss :-) I'll go through them one by one:
Memory Management
Rene Brun brought up the question of how to implement arenas (aka pools in the FORTRAN times) in C++. Ideally one would have a memory arena that stays for the whole process (e.g. magnetic field etc), and one that contains the event data and that gets flushed after every event, without worrying about leaks or destructors.
The major difference between C++ and FORTRAN and also the major problem is C++'s support of pointers: an object can be allocated in the proper arena (e.g. using new with placement), but how do you tell the object to put whatever it allocated into the same arena?
C++ 0x offers scoped allocators which can help. One can pass such an allocator around, allowing to create an object and all its owned objects (I assume that's what the scoped stands for) to be allocated in a certain way, e.g. in a certain arena. No need for templates, but the sub-objects must be smart enough to actually make use the allocator, i.e. it only works for hand-crafted classes. Which should be fine for the experiments' EDM.
The remaining issue is how to reduce the memory fragmentation for long-lasting arenas where parts get deleted and holes are created: to move pointers around one would need another level of indirection. Bjarne Stroustrup told us that there is a development towards "pointers' values are not memory addresses", i.e. an abstraction in the runtime or the OS, allowing a memory page to be moved if there is a free page between two allocated ones, and thus reducing the fragmentation.
Another way of C++ 0x to help with memory management is its optional garbage collection. Well, would have been garbage collection. A few strong voices lobbied so much against garbage collection that in the end only a garbage collection ABI will be part of the (current snapshot of the) standard; the actual implementation can be provided by libraries or the compilers, but there is no guaranteed, standard implementation.
I hope to be welcome you again for the next edition, where I will give the summary of the other points we discussed: threading, symbols, and reflection.
Cheers,
Axel