|
![](/i/fill.gif) |
In article <3ACC23F7.B8BCEFD8@aetec.ee> , Vahur Krouverk
<vah### [at] aetec ee> 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
|
![](/i/fill.gif) |