Difference between revisions of "Contrib equationReader/Efficiency"

Revision as of 15:47, 22 September 2011

How fast is equationReader?

equationReader takes between 10 to 20 times longer than a hard-coded solution. This is because it is currently interpretive. I thought the fancy function-pointer framework I used would be faster, but it isn't. Don't despair, the next version will actually compile your equations on the fly... in theory this will make it equal that of a hard-coded solution.

1 Efficiency discussion

1.1 Parsing and evaluating

There is a difference between parsing and evaluating. When the equation is first read, it is a human-readable string expression. equationReader translates the human-readable form into an operation list. This is parsing. To calculate the result, equationReader does a forAll(operations, i). This is evaluating.

Parsing happens only once, and is slow. Evaluating happens at every cell index, at every timestep (or however you've used it), and it is fast.

1.2 Burn all conditionals

Conditionals are slow. In the framework of equationReader, one if or switch slows a single equation operation by about 25%. A word comparison - that slows things by over 1600%.

equationReader has a design philosophy: put no conditionals in the way of an evaluate function. To achieve this I implemented a function-pointer framework.

1.3 Function-pointers

Apparently in C++ you can have pointers to functions. The syntax looks a little odd:

       void (Foam::equationReader::*reportScalarOperationFunction_)
       (
           const label&,
           const label&
       ) const;

That's not a function - it's a pointer. You don't see these too often because C++'s virtual functions do the same thing - only you need a hierarchy of derived classes. In theory, virtual functions have slightly more overhead than function-pointers because each virtual function call requires a hash-table look-up, unlike the direct use of function-pointers.

Anyway, these function pointers can all be assigned during parsing, and called directly during evaluation. Essentially this moves all conditionals into the parser, and their result is permanently remembered. In short: these make equationReader faster.

Now, there's not a single conditional encountered during an evaluate function call. Even all the debug switches have been converted to function-pointers.

1.4 Function objects

Apparently function-pointers are old-school, and the next best thing are function-objects, or "functors". Function-objects are better because they can be inlined, unlike function-pointers. Well, I didn't get the memo until it was too late for this version. Maybe in another version.

@@ Line 1: / Line 1: @@
 ''How fast is '''equationReader'''?''
-Preliminary results are in, and they are a little disappointing.  '''equationReader''' seems to take between 10 to 20 times longer than a hard-coded solution, depending on the equation involved, and the type of evaluation.  I will upload results of my experiment when I have the time.  If you don't plan on using it within your main solver loop, this isn't a big deal, but if you do, the question is: do the benefits of flexibility outweigh the cost?
+'''equationReader''' takes between 10 to 20 times longer than a hard-coded solution.  This is because it is currently interpretive.  I thought the fancy ''function-pointer'' framework I used would be faster, but it isn't.  Don't despair, the next version will actually ''compile'' your equations on the fly... in theory this will make it equal that of a hard-coded solution.
-Also, expect '''equationReader''' to get faster with future updates.  I used a ''function-pointer'' framework, and should have used a ''function object''... or maybe even defined an entire set of derived objects, one for each operation type, and inlined its <tt>evaluate</tt> function.
 == Efficiency discussion ==