Hi people. I have a question: How many of you would like to see POV-Ray
work faster? I know I would. Now, I know I am the least qualified person
to comment about this, as I am neither a (good) programmer nor do I know
assembly, but...I believe that POV-Ray could be improved with ASM. And I
think that it indeed should be. Can you imagine how much things could
speed up with some well placed optimizations?

I have personally seen the difference between a program written in pure
C, another version in C+ASM, and a pure ASM version. Needless to say,
the ASM version kicked the C version, but the combined version caught my
eye; it didn't have much ASM, just in the right places, like math and
others, and it really did the trick. It was almost as fast as pure ASM.
Couldn't the POV team make an ASM optimized version of our beloved
raytracer?

Just a thought. Please share.


PS: BTW, has anybody heard anything about the User Documentation
Project?

Post a reply to this message

It would become platform dependent.  I know that Sparc asm and MIPS asm
are different.  The destination registers are in different places in
notation I think.  I don't even know about Intel, isn't there just one
register and the accumelator.  Yuck.  I like thre registers.

Anthony Bennett wrote:
> 
> Hi people. I have a question: How many of you would like to see POV-Ray
> work faster? I know I would. Now, I know I am the least qualified person
> to comment about this, as I am neither a (good) programmer nor do I know
> assembly, but...I believe that POV-Ray could be improved with ASM. And I
> think that it indeed should be. Can you imagine how much things could
> speed up with some well placed optimizations?
> 
> I have personally seen the difference between a program written in pure
> C, another version in C+ASM, and a pure ASM version. Needless to say,
> the ASM version kicked the C version, but the combined version caught my
> eye; it didn't have much ASM, just in the right places, like math and
> others, and it really did the trick. It was almost as fast as pure ASM.
> Couldn't the POV team make an ASM optimized version of our beloved
> raytracer?
> 
> Just a thought. Please share.
> 
> PS: BTW, has anybody heard anything about the User Documentation
> Project?

Post a reply to this message

Anthony Bennett <ben### [at] panamaphoenixnet> writes:

> assembly, but...I believe that POV-Ray could be improved with ASM. And I
> think that it indeed should be. Can you imagine how much things could
> speed up with some well placed optimizations?

No.  At least with dece^H^H^H^Hrecent compilers, the generated code is
as fast as (if not faster than) the one done by hand.  It optimises
plenty of things most of the programmers do not even think at all.
And, it keeps *portable*.  That's the keyword.  See how many people
are waiting for a Unix version of a C (supposedly portable) program
(POV-Ray 3.1 for instance).  Now try to imagine how long it would be
for them to wait for an assembly rewriting of POV-Ray on Sparc, PC,
Alpha, HP, everything...  Place yourself in their position.  Let's
assume you, the DOS'ers (including the Windowsers), are to be the last
platform on which the next version is released.  You will not see it
before two years.  Unacceptable, is it not?

My answer is clearly *no*.  Fast code is the compiler's job.
Compilers are pretty good at it (often better than human
programmers).  Humman's job is powerful code.

Roland.
-- 
Roland Mas

Sauvez un arbre, tuez un castor.

Post a reply to this message

Anthony Bennett <ben### [at] panamaphoenixnet> wrote:

>Hi people. I have a question: How many of you would like to see POV-Ray
>work faster? I know I would. Now, I know I am the least qualified person
>to comment about this, as I am neither a (good) programmer nor do I know
>assembly, but...I believe that POV-Ray could be improved with ASM. And I
>think that it indeed should be. Can you imagine how much things could
>speed up with some well placed optimizations?

It would not make a huge difference. Better algorithms are more important.

And remember, POV spends most of it's time during rendering waiting on the
floating point co-processor. Optimisation isn't going to help that either
(unless you can manage to do some useful integer-related work in parallel).

Post a reply to this message

Personally, render time is not my major beef at this point in time.  You can
do things to render quickly and then merge all of your components together
for a final (or several final) renders.

I would like to see something that allowed me to define a heightfield as a
CSG, then using that as a target, create a function that given an X,Z
coordinate in the heightfield would return the Y value for that point.
This out of all the modifications that could be made to POV would be the
greatest improvement in my mind.

Imagine,all those people who have contributed grass renders... you take your
grass stalks and place them approriately on a gently rolling heightfield.
Every one of them is placed at the right height irregardless of the point on
the heightfield it is generated.

You could randomly place any object on a heightfield at exactly the correct
height without trial and error on every object.  For my specialty, cities
could be generated rolling across a heightfield with buildings placed
correctly in any position on that heightfield without fear of the dreaded
"floating-box" syndrome or the "melted-to-low" oops.

Memory usage is my second gripe.  With the present way in which POV uses
memory when parsing and generating the matrixes it uses to render, at around
120,000 objects, you are out of memory on a machine with 128megs of
memory.   You can push that envelope a bit and you start swapping heavily.
Depending on other resources on your machine, this can crash it since
Windows sucks as an operating system.  (This may not be the case on other
platforms).

Memory utilization may also be improved by generating some way where a
"view" crops out unseen objects so that they are not required for a
particular scene.  If based on the camera position and where you are
looking, get rid of all the objects that do not appear in that view.  This
should be an on/off feature since if you have a highly reflective surface in
your scene, you may be reflecting objects that come from behind and beyond
the view.  You want to retain those objects in order to get the proper
reflections.  However, if you have no reflections, why keep those objects
around wasting precious memory.

That's 3.

Next!
Regards,
Robert J Becraft
aka cas### [at] aolcom

Post a reply to this message

Genesis Toolkit by Schrammel can do this. Check here:

http://www.rhein-ruhr.de/~schrammel/index.htm


Robert J Becraft wrote:
> 
> I would like to see something that allowed me to define a heightfield as a
> CSG, then using that as a target, create a function that given an X,Z
> coordinate in the heightfield would return the Y value for that point.
> This out of all the modifications that could be made to POV would be the
> greatest improvement in my mind.
> 
> Imagine,all those people who have contributed grass renders... you take your
> grass stalks and place them approriately on a gently rolling heightfield.
> Every one of them is placed at the right height irregardless of the point on
> the heightfield it is generated.
> 
> You could randomly place any object on a heightfield at exactly the correct
> height without trial and error on every object.  For my specialty, cities
> could be generated rolling across a heightfield with buildings placed
> correctly in any position on that heightfield without fear of the dreaded
> "floating-box" syndrome or the "melted-to-low" oops.
>
> Regards,
> Robert J Becraft
> aka cas### [at] aolcom

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Roland Mas <rol### [at] casimirrezelenstfr> wrote:
: No.  At least with dece^H^H^H^Hrecent compilers, the generated code is
: as fast as (if not faster than) the one done by hand.

  This is and isn't true.
  This isn't true, because compilers are not magic programs which can
make asm-code impossible to make by humans. The compilers are made by
humans and the optimizations made by compilers are coded by humans. So
compilers can't do anything a human couldn't do.
  Actually, the optimizations made by a compiler are very schematic. They
always have a limited way of optimizing a code. Humans have not this limit.
They can use their creativity to create a specific asm code which is
optimal for a certain code. Compilers can't do anything that they are not
programmed to do. Humans can.
  But the statement is also true. Although humans can make better code,
they are only humans, with human limits. Humans can't optimize 10^6 lines
of asm code while compilers can. Humans can optimize a little piece of
code, but nothing more. Also the amount of knowledge needed to make
a perfectly optimal code is tremendous, and almost no human can learn that
amount of information. Compilers can.

  Another problem with optimizing programs is the limited expressive power
of programming languages. For example (in PC with C) you can't rotate the
contents of a variable with a single operation (if you use a=(a<<10)|(a>>22);
some compilers see the rotation there and can compile that to one single
asm instruction, but those compilers are very rare), you can't multiply
two 32-bit integers and get the upper 32 bits of the result (which is
a 64-bit number stored into two registers), you can't use the carry flag
in any way (for example for adding two numbers which are larger than 32 bits),
etc. With asm you can.

  I once tested asm vs C. I made a C-code which calculated the mandelbrot
fractal to memory. I tried to make the C-code as optimal as possible. Then
I made the same thing with asm. The asm-code was about two times as fast
as the C-code.
  I used many optimizing tricks in the asm code which are impossible to
achieve with the C-code (because they use intel cpu specific features).
For example, I could store _all_ the required floating point values into
the FPU and didn't have to load and store them in each loop (as the
C-compiler did). The C-compiler was unable to see that he actually didn't
have to temporarily store the values to memory from the FPU. (The mandelbrot
fractal is a bit unfair example since you need only about 7 values to
calculate it, and there are 8 register into the FPU. It seems that the
compiler can't see this.) Of course this is compiler-dependant. Perhaps
another compiler could see this.
  Another funny trick was that with the intel asm I could test two things
with just one jump command. In the inner loop you have to test if a value
is bigger than 4. If so, you have to end the loop. Also you have to test if
you have looped the maximum number of iterations. Ie. something like this:
  n=MaxIterations;
  do
  { ...
    if(a>4) break;
    n--;
  } while(n>0);

  I could do it this way:

  cmp 4,[a]  ; (Actually it's not 4 but the floating point presentation of 4)
  dec Cl     ; equivalent to n--;
  ja Loop    ; if [a]<=4 and Cl!=0 then loop

(I'm not completely sure about the 'ja' command, but at least this is the
idea)
  This is possible because the 'dec' instruction doesn't change the carry
flag.
  And here is another optimization. As I commented, the value to which I
compare the 'a' is not 4 but the floating point representation of it (I
don't remember how is it); of course 'a' is also in floating point format.
Since 'a' is always positive (it's the sum of two squared values) and the
floating point format in the PC is the IEEE standard format, I can compare
them directly, as if they were just integers.
  The compiler can't do this. That comparation doesn't work if 'a' is
negative, but the compiler has no way to know that it will never be
a negative value, so it just can't optimize that. Also the
2-compares-in-1-jump is also almost impossible to see by a compiler.


  Of course this is just a very very short program. It isn't affected by
cache miss penalties or anything. With a bigger program which uses more
memory it would be a lot harder to beat the compiler.

  As someone said, a good algorithm will speed up more with less work than
optimizing the code by hand.
  Of course a Perfectly Optimized Povray would use the best algorithms and
would be made entirely with perfeclty optimized asm. The making of such
program would take centuries... (just for one platform).

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika <war### [at] cctutfi> wrote:

>Roland Mas <rol### [at] casimirrezelenstfr> wrote:
>: No.  At least with dece^H^H^H^Hrecent compilers, the generated code is
>: as fast as (if not faster than) the one done by hand.
>
>  This is and isn't true.
>  This isn't true, because compilers are not magic programs which can
>make asm-code impossible to make by humans. The compilers are made by
>humans and the optimizations made by compilers are coded by humans. So
>compilers can't do anything a human couldn't do.

In a perfect world, this would be true.

However, the fact is that there are a number of specific optimisation
strategies available for Pentium-class processors (particularly P2 and better)
that are the subject of NDA's from Intel. They are also very hard to achieve by
hand, even if you knew what they were (they involve, I believe, things such as
pipeline scheduling, arrangement of instructions to suit the way the CPU
prefetches, etc).

Needless to say, the big compiler vendors have access to this information. We
don't.

Post a reply to this message

Thanks for the comments people. I still feel that it could and should be
optimized if possible. Since I don't know anything about raytracing, except
that there is a lot of math involved, I think that that should be the target
area. It doesn't have to be the POV team that does this, they can put out
their C version quickly and easily and someone like Warp (just an example, I
don't want to overload you with more work) could stick in optimizations
where they would indeed improve the speed of calculations.

Anyway, I'm glad I got people talking. Please try to stay within the
discussed subject, don't change it half-way through. It's annoying. Post
these things separately. Thanks. Have a nice day. =)

Post a reply to this message

There is info out there, though...

http://www.goof.com/pcg/docs.html

...anyone know how complete this is?

-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"A ship in a harbor is safe, but that is not what ships are built for"
                                            -- William Shedd

Post a reply to this message