> Let me stick my two cents in on performance. When you are writing an > application, you should not worry too much about performance until you > measure, profile, and quantify, find out where the bottlenecks are, and > then fix those. I agree that in many cases fast computers are making > issues that used to be important moot. > > However, when you build a library, this is completely different. Since > you're building it (hopefully) for general use and re-use, you do not > have any constraint on the application people will eventually put it > to, and so you should make it as lean and mean as possible. So why isn't Root written in assembly language? Obviously whatever efficiency one can get is desirable, but I also think compromises are inevitable, and therefore it's a question of degree where one draws the line between optimal code and flexibility/ease of understanding. > In concrete terms for TVector3: Who are you to say that some user of > ROOT will not need or want to work with groups of millions or tens of > millions or even hundreds of millions of these objects? I can certainly > conceive such applications. What sort of applications are you conceiving of which have hundreds of millions of such objects? Maybe Tomb Raider 4, but even there I tend to doubt it, and anyway Tomb Raider 4 should probably not be based on Root. It was my understanding that Root was primarily aimed at high energy physics. Therefore I think it's design should be geared toward a typical HEP program - maybe O(100,000) vectors in an extreme case, but 100,000,000 seems kind of implausible to me. And anyway, if you are writing a program using 100M vectors, presumably you are running it on a machine which has appropriately lavish resources. Your philosophy would seem to me to hamstring the much more common simple applications where one wants to do a modest calculation in the most straight-forward way and avoid unnecessary hassle (e.g. wrapping a perfectly good vector class by hand rather than inheriting it). It seems more reasonable to me to provide classes which are easy to use for typical applications, and figure anyone concerned with performance at the few percent level can customize according to their needs, rather than require complicated machinations to re-use basic functionality in typical small applications. > Root should endeavor for as many people as possible to be > able to use their classes without having to 'roll their own' for > performance reasons. Well, it should also not force people to "roll their own" because trivial functionality (like inheritance) is prevented by the design either. Assuming we are talking about physics applications, it is not so hard to think of domain elements which logically "are" vectors, and therefore should reasonably inherit vector behavior. I still maintain that in any plausible application, performance will not be dependent on small optimizations in classes like TVector3 or TLorentzVector, but rather on the meat of the calculation. And these classes have several dozen methods, so encapsulation is a significant pain (i.e. writing a wrapper for every method which simply calls the method you wanted to inherit but couldn't). Dave dcasper@uci.edu
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:35 MET