In article <3dbda450@news.povray.org>,
 Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:

> Heh, very nice. I know it is a bit early and doing things at parse-time 
> isn't what G is targeted for, but could you say something about the speed 
> differences between #macros and compiled G functions, for instance in your 
> above example?

Actually, this was all done at parse time. They do work at render time, 
though I haven't made many tests of this.
About the speed: probably a lot closer to the existing POV functions 
than to parsing. It doesn't do any optimization, but evaluating the 
opcodes will be far faster than interpreting scene code directly. A 
simple loop got about half a million iterations per second on my system, 
POV gets closer to a few thousand (it was just a simple do-nothing loop 
though, so no real measure of speed, and will be faster when increment 
and decrement operations are added).
Replacing macros with G functions for math calculations could gain a lot 
of speed, but you can't manipulate things like POV objects (not yet, at 
least). Also, G functions should handle recursion with no problems (this 
is untested, though). And since POV functions can't take vector 
parameters, you have to split vectors into three float parameters to 
pass them to G functions (since G functions are accessed through POV 
functions).

So compared to POV: very fast. Compared to the existing POV VM: probably 
quite slow for simple things, but since it allows things that can 
eliminate a lot of duplicate computations necessary in POV functions, it 
could be a lot faster for some problems.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message