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

> Could someone disclose the secret of this "trick"? I'd like to know, how
> was this acieved? Are isosurface functions precompiled in some way? Or
> is the isosurface potential value calculation algorithm changed, which
> allows this speedup ("minor slowdown")?

The minor slowdown is caused by more overhead starting to evaluate a
function.  The speedup is due to a (very simple) VM architecture and
support for optimization of expressions.

>> However, all noteworthy limits in function size are eliminated
>> and there are hooks that could allow another factor of ten speedup (no
>> kidding!)...
>
> How do these hooks work?

They allow you to take the VM code and generate native code prior to
rendering.  Since every VM instruction takes about 15-20 native
instructions, you can reduce the code executed to about 1/15-1/20 by
compiling.  However, since you get better pipelining effects when using
the VM, the speedup will be a bit lower than the 15-20 times maximum.
It will actually be less if you call "slow" native functions like sin or
sqrt (because then the VM overhead will be a smaller percentage of the
whole), but you get a factor of about ten for functions that use only
basic math.

> Vahur,
> who can't wait for release of 3.5 to examine source code...

You? ;-)


     Thorsten

Post a reply to this message