Hi all

Spoke to a guy working on a thermodynamics program for nuclear reactor
heatflow simulations today. Didn't quite get a grab on the following: he
said he is working on a system to optimize calculations (especially
matrices) and to move much of the work of doing the matrix calculcations
into the compile phase of the creation of their thermodynamics / fluid
simulation programs. It apparently has to do with eliminating the creation
of temporary variables.

It is apparently based on "tokenizing" various well known / or repeated
sequences of calculations and then snapping together parts of the equation
during compile time, thus increasing compile time but decreasing runtime in
order to yield (according to him) up to a 30% speed increase for compute
intensive problems (like thermo / fluid dynamics) with sufficient
similarity so that a "compile shifted" program will actually offer an
advantage (i. e. not throwing equations at it that are so dissimilar that
the assemblage has to be recompiled).

I have extremely little mathematical background - I asked him and he said he
thinks that raytracing (which apparently uses lots of matrices) should be
able to benefit enormously from this process, especially radiosity.

It sounds very cutting edge (or impossible, or I am too stupid to understand
him) but he IS working in this company and according to what I have been
able to dredge up their software is cutting edge stuff - apparently already
maybe using this person's techniques - he is a qualified engineer /
programmer as well. 

Anybody ever heard of this "compile shift optimization" for raytracing type
operations? Or of this theory at all? Any possibility this technique MIGHT
be able to be incorporated into PovRay to accelerate it? It seems extremely
complicated and requiring a deep understanding of calculus. Has this been
implemented somewhere or is it just a genius' theory, still to be proven
practical? I. e. shifting "processing" into compile time?

Anyway, awaiting some of the extremely intelligent ppl in here's replies.
-- 
Stefan Viljoen
Software Support Technician
Polar Design Solutions

Post a reply to this message

Very interesting that you're mentioning this, as I was thinking today if
it's worth the effort to hard-code sdl-scenes into the sourcecode of
pov-ray.
Compiling this would result in a scene-specific executable that might a bit
faster than the run-time parsing and rendering with the general pov-ray.

So this all would lead to a sequence like this:

1.
User writes good old POV-Ray sdl code

2.
User compiles and links the code, resulting in a standalone executable

3.
User runs the executable and waits patiently until the render is finished

Post a reply to this message

In article <410bfd8d@news.povray.org> , Stefan Viljoen 
<rylan@<deletehis>intekom.co.za>  wrote:

> I have extremely little mathematical background - I asked him and he said he
> thinks that raytracing (which apparently uses lots of matrices)

You are mistaken.  We are talking about a few 4*4 matrices while the person
you talked to is dealing with huge matrices with hundreds of rows and
columns.  While matrices may well be the bottleneck in his application, they
are not a bottleneck in ray-tracing at all.

    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

Thorsten Froehlich wrote:

> In article <410bfd8d@news.povray.org> , Stefan Viljoen
> <rylan@<deletehis>intekom.co.za>  wrote:
> 
>> I have extremely little mathematical background - I asked him and he said
>> he thinks that raytracing (which apparently uses lots of matrices)
> 
> You are mistaken.  We are talking about a few 4*4 matrices while the
> person you talked to is dealing with huge matrices with hundreds of rows
> and
> columns.  While matrices may well be the bottleneck in his application,
> they are not a bottleneck in ray-tracing at all.
> 
>     Thorsten
> 
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
> 
> Visit POV-Ray on the web: http://mac.povray.org

Oh ok! Thanks Thorsten that's cleared it up for me.

-- 
Stefan Viljoen
Software Support Technician
Polar Design Solutions

Post a reply to this message