Best performing use of boost::spirit

[Paul van Hagen]

Hello,

I've been doing some research as to ways to optimise our parsing and
evaluation of mathematical expressions and came across the spirit template
library as part of the boost library.
It looks like for the parsing bit that library provides everything we need.
However, I'm still pondering about the best performing options for the
evaluation part. The idea is to evaluate the same expressions many times
with different values. Conventionally, you'd set up a parse tree and walk
down that tree to arrive at the endresult. I have been thinking about
alternative approaches using expression templates for the evaluation part
(lambda??)
Is there any use of the boost::spirit template library in combination with
the use of expression templates for evaluation? Are there any code samples
that demonstrate that combination?

TIA

P.

 

[Mirek Fidler]

evaluation part. The idea is to evaluate the same expressions many times

with different values. Conventionally, you'd set up a parse tree and walk
down that tree to arrive at the endresult.

Another common way is to create some form of stack based p-code, but I
guess you know that pretty well

Maybe, if you need really the max performance, one could even think
about compiling into the real code (invoking C compiler and dynamically
link created .so should not be as hard nor slow....)

Mirek

P.S.: Sorry for now answering your question, I found this topic to be
interesting and could not resist adding my 0.02

 

[Paul van Hagen]

I have thought about generating C++ and dynamically link that to our .so
libs. That has a trade-off, however, in that you'd probably need to release
a compiler with your application and possible source dependencies which is
something I don't like.

 

[Mirek Fidler]

I have thought about generating C++ and dynamically link that to our .so
libs. That has a trade-off, however, in that you'd probably need to release
a compiler with your application and possible source dependencies which is
something I don't like.

Well, I guess than on any *x platform you could count on invoking "gcc".
At least, you can count to have some c compiler there... and possible
command-line differences will be just part of porting...

As for source dependencies, I think that generated code should use just
minimal standard headers (if any), perhaps just "math.h", so I do not
see too much danger with source dependencies... But of course, this
depends on what kind of expresions are you going to deal with.

Moreover, if you are even more ambitios, you can even think about
avoiding compiler and generate the code by your app. Even that might not
be as hard as it seems... (but of course, you will have to do it again
for any CPU you are porting to..)

That said, I really like your original idea of representing expression
using some form composed functor. I guess that it will be the second
fastest solution to compiled code....

Mirek