[GiNaC-devel] GiNaC is not a C compiler [Was: Optimized C-style output]

Stefan Weinzierl stefanw at thep.physik.uni-mainz.de
Wed Mar 21 11:25:21 CET 2007


Dear Alexei,

I think you miss the point. A typical situation were the generation of C
code is useful, is the following:
You use GiNaC to compute symbolically  a rather large expression which
depends on a handful symbols.
You then want to evaluate this expression numerically a large number of
times for different values of the variables/symbols ( a typical example is
Monte Carlo integration).
There are two large quantities in the game: The size of the expression
and the number of evaluations.

I believe an efficient way to do this is to write the expression as C code
into a file, compile and reload the compiled function into memory.

There is certainly an overhead involved for the time needed to generate
the C code and the compilation, but this occurs only once and is usually
outweighted by the speed improvement of a single evaluation.

To give an example I took an expression, which I want to evaluate 10^6
times.
A single evaluation with evalf() takes 0.55 s.

If I use the plain print_csrc routine build into GiNaC, the code is
generated in less than a second, compilation takes 74s, but the time for a
single evaluation improves to 3.8 10^-3 s.

If I take the routine for the generation of optimized code, code
generation takes 49s (yes, code optimization has a price, but you pay only
once), compilation takes 7 s, and the time for a single evaluation is now
3.2 10^-4 s.

So the total cost for one million evaluations is
 evalf() :       550000 s
 standard csrc:    3875 s
 optimized:         376 s

Therefore I don't understand why you propose evalf(), the difference in
cost are orders of magnitude.

A few more comments: I agree that GiNaC is not a compiler, but a nice
feature is that it is based on C++ and should therefore allow the
combination of symbolic and numerical code.
Generating optimized C code is a feature I miss in GiNaC.

Finally, one should make the attempt to generate "the" optimal code,
anything which performs better than the standard csrc output is already an
improvment.

 Best wishes,

       Stefan





More information about the GiNaC-devel mailing list