In article <3ACC9732.D22D35CA@aetec.ee> , Vahur Krouverk 
<vah### [at] aetecee>  wrote:

> Ahah! This (esp. optimization) may become handy in shading language VM
> as well. I've thought, that it would be good, if isosurface and shading
> language use same VM, for they are quite similar (talking within my
> limited knowledge of iso functions, of course!) but this is still more
> work than I want to do, especially now when 3.5 is around a corner.
> Expression optimization: does this mean, that if expression's value does
> not depend from run-time variables (e.g. sin(45)/sqrt(2)?), then its
> value calculation is done beforehand?

It will right now do it for anything that has an immediate internal
instruction in the VM.  So sqrt(2) would be turned into 1.4142... but
sin(45) would not be further optimised.  The code would support
optimising sin, cos, tan, etc but there are so many functions and some
with special requirements...

> I've thought about doing this in
> shading language compiler, but this is another not-yet-done thing.

The 3.5 code is a rewrite of the function parser in isosurfaces.  I
don't think you can really fix that messy parser.

> I'm interested in this approach (thinking again about SL VM). Is this
> "home-made" solution or are there publications available about this
> technique? Will this hooking solve cross-platform compatibility?

It works just like any other JIT.  By default the interpreting VM is
used, but at compile time (talking about POV-Ray) you can switch to use
a platform specific VM or JIT code to replace it (not really
just-in-time because it is done before rendering without knowing if it
is ever going to be used, but close).


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message