| Thread Previous • Date Previous • Date Next • Thread Next |
> On Thu, Sep 02, 2004 at 08:01:29AM -0700, Anders Logg wrote: > > ok, what does Johan J think? > > > > /Anders > > > > I'm still thinking about the impact of having virtual functions (both > in the user-defined case, but also in the envelope-letter design). If > we are doing a redesign, now would be the time to consider this. ok. > I'm still not sure about the magnitude of the overhead though. You can > find qualitative statements such as: > > http://www-2.cs.cmu.edu/~gilpin/c++/performance.html > > "Virtual functions negatively affect performance in 3 main ways: > > 1. The constructor of an object containing virtual functions must > initialize the vptr table, which is the table of pointers to its > member functions. No problem. A Function is often a large object which is created once and accessed many times. > 2. Virtual functions are called using pointer indirection, which > results in a few extra instructions per method invocation as compared > to a non-virtual method invocation. ok. > 3. Virtual functions whose resolution is only known at run-time cannot > be inlined. > > ... ok. > The cost of using virtual functions is usually not a factor in calling > methods that take a long time to execute since the call overhead is > dominated by the method itself. In smaller methods, for example > accessor methods, the cost of virtual functions is more important. > > ... > > Inlining is one of the easiest optimizations to use in C++ and it can > result in the most dramatic improvements in execution speed. The main > thing to know when using inlining is when you should inline a method > and when you shouldn't inline. > " > > It's primarily #3 and the last paragraph that is relevant. The > evaluation of a Function is probably often a simple operation, and > perhaps the gain from inlining would be significant. One of the central places where we will use the class Function will be (and is) inside the assembly where a local function (restriction, currently an ElementFunction) needs to be updated with the values on the current element. I think the way to do this would be to have a method update() in the class Function which takes the restriction and updates the local values. Since most of the work would be inside the method update() I don't think the overhead of an extra indirection will be significant. > What we need is some quantitive information. > > This is one article I found, but I don't think it considers inlining: > > http://portal.acm.org/citation.cfm?id=236338.236369 > > Perhaps it's not relevant. If the assembler spends most of its time > doing sparse matrix operations or something similar, then a 10-50% > efficiency gain in function evaluation might not matter. But if > evaluation functions (coefficients for example) is a significant cost, > then it might pay off to stay away from virtual functions. > > Perhaps we can wait a couple of days more and try to figure this out a > bit more, perhaps do some benchmarks, then we can decide. Sure, ok. > If we move away from virtual functions, then that will be quite a > significant design change, so there has to be some significant gain. I agree. My basic standpoint on this is that we should use the features of C++ (inheritance, virtual functions) whenever we can to get a good object-oriented design and when necessary for performance reasons move stuff inside function calls, such as having an update() method in Function. /Anders
| Thread Previous • Date Previous • Date Next • Thread Next |
