Warp <war### [at] tagpovrayorg> wrote:
>   OTOH, if you are making every operation to 64 items at a time in a loop,
> then maybe JIT compiling won't make *that* significantly faster...
Warp <war### [at] tagpovrayorg> wrote:
>   OTOH, if you are making every operation to 64 items at a time in a loop,
> then maybe JIT compiling won't make *that* significantly faster...
Hello,
First, Thank you for your work on fparser, it's really a great job.
I just made some tests with multithreading support and it's also promising.
I don't know about the JIT compiling but I think that graphical applications
like Povray and K3DSurf should take advantage of there math objetcs and give
a parser some hints on the math objects they are handling: isosurfaces
(dim=3)should not be treated like a single point (dim=0) by the parser and
the internal stack of the parser should be one dimension more than the
object it performs. This new parser has the advantage that it uses 100% of
the old one, will take advantage of all opcode optimisation and we don't
have to write a new one from scratch: all to do is just write some special
Eval() fcts suitables for every math object the application is able to
handle (Isosurfaces (dim=3), parametriques(dim=2), simple fcts(dim=1),
point (dim=0) ). It's even possible to write a single new fct Eval() and
use it for heigher dimensional object: we can for example use an Eval() fct
made for "simple fcts" (dimension = 1) to perform parametric object ( by
calculating the parametric  map line by line) and Isosurfaces (by
calculating line by line and layer by layer). We can also use an Eval() fct
suitible for calculating objetc with dim =2 (parametric map) to perform
isosurfaces layer by layer (that's what I'm planing to do in the future).
Also, it's a scalable parser since it's easy to change the number of
operations it can perform in the loop and by doing so approching the
"theorical" maximum number of calculations the hardware is able to do
(since most of the CPU time will be used in series of independants
calculations).
As tests shows, examples run up to 5 times faster (the fastest examples are
"Shmutov_2" and "Pseudo_Duplin" in the last k3dsurf-0613-Unstable) but it's
easy to see that it will run faster with "big" functions (since some time is
economised from the  loop).
Cheers,
Taha

Post a reply to this message