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

This I GOT.  This works fine if you want to reiteratively place objects on your
scene.  It does not provide me any means of ascertaining the height on the
heightfield for individually placed items.

A simple scattering loop looks like this:

#declare R1=seed(3838)
#declare Count=1
#while (Count<100)
    #declare X=rand(R1)*100
    #declare Z=rand(R1)*100
    #declare Y=somefunction(HFNAME, X,Z,100,100)
    object{TheTHING translate<X,Y,Z>}
    #declare Count=Count+1
#end

This does a random scatter of 100 items across an area bounded 0,0,0 to 100,?,100
where "somefunction" delivers the Y coordinate.

Schrammel's toolkit is wonderful but very complicated to setup and use for the
kind of work I want to do with POV.  The above example would work fine with his
tool since it only uses 1 item named "TheTHING" ... however, my "TheTHING" becomes
an entire case statement where "TheTHING" can be any of a hundred items (depending
on what I'm rendering, this can be more or less).

In order to use the utility, EACH and every item in the 100 items would have to
have the program run 1ce for each item.  Then all the output files combined to
render it.  If any of the items collided, I couldn't just change the seed R1 value
to resolve them, I'd have to regenerate EVERY one of the include files generated
and hope that they didn't collide again.

Bob Hughes wrote:

> Genesis Toolkit by Schrammel can do this. Check here:
>
> http://www.rhein-ruhr.de/~schrammel/index.htm
>

Post a reply to this message

> 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,

Yeah, but C (or C++) isn't the best language to be optimizing for. There's a
story about Ada running circles around assembly - a newly hired Ada programmer
with only a dab of experience wrote code that outperformed what a team of
experienced assembly programmers came up with.  I can't find the URL for that
story, but it's been passed around a lot in Ada circles.  Like chess playing
programs, it's not smarts, but applying simple rules that humans understand
just fine, but unrelenting, more combinations and moves ahead. Turns out
there's almost always nothing to be gained by using clever opcodes, except on
older CPUs like the 486.  Pipelining in the Pentium is a more important
concern.


More stuff at 
http://www.acm.org/sigada/news/news.html 
and
http://www.adahome.com/

And as long as I'm on my favorite soapbox, anyone thinking of switching from C
or C++  to something capable of global optimizations, should pay a visit to
http://www.m3.org/.  (Ha, my only published ray tracing from all of 1998)


For anyone wanting to stick with C or C++, you gotta look into the PGCC
compiler with Pentium optimizations (good for all platforms using pentium and
any flavor of unix, heck, maybe there's a win32 port?)   

But for totally cross-platform optimizing, use a platform  independent language
like Ada-95 or Modula-3, and let the compiler do all hard work.

-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"Ada 95 is about the best language out there
 and people are beginning to notice. C++ seems to be evolving 
 into a monster and people cannot fail to notice that."
              -- Michael Rohan

Post a reply to this message

Robert J Becraft wrote:
> 
> This I GOT.  This works fine if you want to reiteratively place objects on your
> scene.  It does not provide me any means of ascertaining the height on the
> heightfield for individually placed items.
> 
> A simple scattering loop looks like this:
> 
> #declare R1=seed(3838)
> #declare Count=1
> #while (Count<100)
>     #declare X=rand(R1)*100
>     #declare Z=rand(R1)*100
>     #declare Y=somefunction(HFNAME, X,Z,100,100)
>     object{TheTHING translate<X,Y,Z>}
>     #declare Count=Count+1
> #end
> 
> This does a random scatter of 100 items across an area bounded 0,0,0 to 100,?,100
> where "somefunction" delivers the Y coordinate.
> 
> Schrammel's toolkit is wonderful but very complicated to setup and use for the
> kind of work I want to do with POV.  The above example would work fine with his
> tool since it only uses 1 item named "TheTHING" ... however, my "TheTHING" becomes
> an entire case statement where "TheTHING" can be any of a hundred items (depending
> on what I'm rendering, this can be more or less).
> 
> In order to use the utility, EACH and every item in the 100 items would have to
> have the program run 1ce for each item.  Then all the output files combined to
> render it.  If any of the items collided, I couldn't just change the seed R1 value
> to resolve them, I'd have to regenerate EVERY one of the include files generated
> and hope that they didn't collide again.
> 
> Bob Hughes wrote:
> 
> > Genesis Toolkit by Schrammel can do this. Check here:
> >
> > http://www.rhein-ruhr.de/~schrammel/index.htm
> >

  If it's just random distributed points (locations for "TheTHING" )
on a terrain then you are looking, for Ray Gardeners program Leveller,
has this function available. It allows you to choose some variables of
the process, such as % per grid point or % of the entire HF and number
of points to generate, and then will export these point coordinates in
an array of 3d coordinates. You then use the array in a while a loop to
translate your choosen "TheTHING" to their respective locations. 
   Since the program knows where each elevation point is along the grid
it's output gives very accuarate placement of "TheTHING" or group of
"TheTHINGS". There is also an option at the time of the export where
it will provide a sample Pov script for the proper use of the while
loop in conjunction with the array to "TheTHING" to their final matching
positions along the topography of the height field.
  The export points feature is a somewhat limit function in that is is not
constrained to a selectable area rather it is ditributed across the entire
grid based upon the percentages you choose in the setup fields. The only
constraing option that I am aware of is you may choose an elevation cutoff
point that works much the same as the water level does in Pov. This way
you will have "TheTHING" restricted to points that are higher than that
elevation you choose as the demarcation line.
  There are other tools in the program that make it possible to measure
a point on the field but I wouldn't try this for more than a hand full
of objects since as far as I know you would have to copy the information
down and use it later when you set up your scene file. It would be tedious
with many objects invoved, but also may prove invaluable for placing a
couple of buildings on a hill, or a string of fence posts up a slope,
that other wise would take way too much trail and error to get
positioned right otherwise.

Leveller may be found at: http://www.daylongraphics.com/

His ISP is giving him problems with access right now due to equipment
changes. If it shows up missing or inactive try back in a couple days
and it should be there.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Robert J Becraft wrote in message <36C### [at] aolcom>...
>
>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.
>

Unless you are opposed to using an unofficial compile of POV, I suggest you
get the Superpatch. It has a trace() function that does what you want.
Example:
trace(MyHeightField,StartPoint,Dir,Normal);

This traces a ray from StartPoint in direction Dir and if MyHeightField is
hit, returns the intersection point. It also stores the surface normal of
that point in a pre-declared identifier "Normal", if it's provided.
I have found this function incredibly useful; my "shaggy" images were made
using it.

Margus

Post a reply to this message

Have to come in here a bit.
I've spent some time coding(a few years, more or less) and I have tried
most of the languages avaiable, Mostly the larger common ones. As I have
a friend, who is Asm addicted, as well as a C-coder, I took part of his
examples. using the borland c compiler, not the best, not the worst, he
made a simple algorithm to change a string in certain ways, first in C,
then in asm. After that, we peeked at the asm output that the compiler
made. it was some 400% larger both in code and instrucioon wise.(don't
ask details, I don't remember).

This gives, together with most specific ideas, that a smaller
function/code-pice is very much more effective in ASM than In any
language, and that is where asm code would give the best results, in
smaller, commonly used functions.


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

I love your heightfield idea, and I have another.
Why not make a heightfield function, but instead of taking an image as
the original object, take a texture or pigment statement. using a
image_map you get the old typpe heightfield, and using any other
pigment, you can loose one stage in hf useage procedure. (many of us
create our height_fields in pov)
Sure, the pigment will need some scaling in all directions to fit
nicely, but this can't be a trouble for the coder. Anyone catching my
idea ?




-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

A ine pice of asm coding :
http://www.algonet.se/~redhog/
He's currently coding a OS in asm. As far as I know he's already made
the multitasker....


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

portelli schrieb in Nachricht <36CD28A6.48AB9F3E@pilot.msu.edu>...
>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.

I think you're confusing the current PCs with the Apple ][ <g>.

A modern Intel CPU has more than one register and can use more than one
register to do calculations.

But of course, assembler is (most of the time) different on different CPUs.
--
Rudy Velthuis

Post a reply to this message

Again, check out the Superpatch. It can do a procedural height field, i.e.
it takes an ordinary POV texture instead of a bitmap.

Margus

Spider wrote in message <36CDACEB.3945631F@bahnhof.se>...
>I love your heightfield idea, and I have another.
>Why not make a heightfield function, but instead of taking an image as
>the original object, take a texture or pigment statement. using a
>image_map you get the old typpe heightfield, and using any other
>pigment, you can loose one stage in hf useage procedure. (many of us
>create our height_fields in pov)
>Sure, the pigment will need some scaling in all directions to fit
>nicely, but this can't be a trouble for the coder. Anyone catching my
>idea ?
>
>
>
>
>--
>//Spider
>( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
>#declare life = rand(seed(42))*sqrt(-1);
>
>

Post a reply to this message

Spider schrieb in Nachricht <36CDAD6D.3F026D07@bahnhof.se>...
>A ine pice of asm coding :
>http://www.algonet.se/~redhog/
>He's currently coding a OS in asm. As far as I know he's already made
>the multitasker....

Believe it or not... but when I was 20, I have coded a simple OS (16k ROM
based OS) for my Acorn BBC-B home computer once, because the one provided
with my double density floppy controller (Acorn only offered single density
then) had too many bugs. So I started writing one from scratch in
BBC-Basic-Assmbler (the assembler was integrated in the Basic and could for
instance use Basic functions as macros and special integer variables as
compile pointers). As memory was a problem, I had to chain several files
together to compile to "upper RAM" (in ROM space) directly. This was
hand-optimised 6502 code. Of course it was not multi-tasking. It was used by
many friends who had the same controller.

A language like Inprise Borland Object Pascal and the component library VCL
uses assembler in time-critical parts (sorting, string functions) or in
parts, where a call couldn't easily be faked using high level Pascal
(because something like non-standard stack handling is required). I've
however seen one example, where optimized Pascal code was *faster* than the
original hand-optimized assembler routine. This was also a string function.
It was the improved algorithm which did the trick.

--
Rudy Velthuis

Post a reply to this message

>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



And I've seen the opposite:  My C++ version of a program with several
indirect function calls and a minimal ASM driver backend blew away a pure
ASM program by a factor of 3 or 4.

Post a reply to this message

povray.org admin team wrote in message <36d233dd.6363046@news.povray.org>...
>Anthony Bennett <ben### [at] panamaphoenixnet> wrote:
>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).


If someone wrote some low-level math routines, like matrix multiply, in ASM
to take advantage of specific special processor features, it =might= make a
difference.

Post a reply to this message

Margus Ramst wrote:
> 
> Again, check out the Superpatch. It can do a procedural height field, 
> i.e. it takes an ordinary POV texture instead of a bitmap.
I think I will have to read more of the doc's in superpatch. I hadn't
found it yet :-)

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Rudy Velthuis wrote:
> 
<snip>

Nifty basic :-)
 

> 
> A language like Inprise Borland Object Pascal and the component library VCL
> uses assembler in time-critical parts (sorting, string functions) or in
> parts, where a call couldn't easily be faked using high level Pascal
> (because something like non-standard stack handling is required). 
I know this about the Delphi environment, and that they used it partly
in OOP pascal.

> I've
> however seen one example, where optimized Pascal code was *faster* than the
> original hand-optimized assembler routine. This was also a string function.
> It was the improved algorithm which did the trick.

Show me that pascal code, please. 

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Spider schrieb in Nachricht <36D01BE3.49F920CE@bahnhof.se>...


>Show me that pascal code, please.

If I can find it, I'll e-mail it to you. It was in one of the
news.inprise.com newsgroups (I think it was borland.objectpascal). It should
have been deleted from my disk by now (I only keep newsgroup messages for 60
days), but I might have saved it somewhere (if I only knew where). Otherwise
try Dejanews or the Delphi Super Page.

But it was the improved algorithm which made the routine faster, not Pascal
of course. I just mentioned this to show, that a clever algorithm is
sometimes better than a "blind" translation to assembler. And even the best
compilers don't develop algorithms yet.

BTW BBC-Basic was really a very nice and fast Basic interpreter. I have even
tested a PC version of it once (1985/86). Only the assembler was different,
of course. And it had problems with the PC graphic resolutions.
--
Rudy Velthuis

Post a reply to this message

Rudy Velthuis wrote:
> 

> Spider schrieb in Nachricht <36D01BE3.49F920CE@bahnhof.se>...
> 

> >Show me that pascal code, please.
> 

> If I can find it, I'll e-mail it to you. It was in one of the
> news.inprise.com newsgroups (I think it was borland.objectpascal). It s
hould
> have been deleted from my disk by now (I only keep newsgroup messages f
or 60
> days), but I might have saved it somewhere (if I only knew where). Othe
rwise
> try Dejanews or the Delphi Super Page.
Ah, I can try, If I knew what to look for... :-)
 

> But it was the improved algorithm which made the routine faster, not Pa
scal
> of course. I just mentioned this to show, that a clever algorithm is
> sometimes better than a "blind" translation to assembler. And even the 
best
> compilers don't develop algorithms yet.
I agree with you. but, often a specific algorthim is better than a
general one, and most specific algorthims can be coded in asm once it is
in a fast High level language. What I mean is that you gain less if you
only trust that "asm is faster" and don't do a good algorithm first.
Bubble-sort is faster in asm than in pascal, but still slower than
ComboSort, SpeedSort or QuickSort. And theese algorithms would probably
be faster in asm than in pascal. (Don't know, I haven't tried. I'm not
_that_ interested in sorting speeds.)

> BTW BBC-Basic was really a very nice and fast Basic interpreter. I have
 even
> tested a PC version of it once (1985/86). Only the assembler was differ
ent,
> of course. And it had problems with the PC graphic resolutions.

Well, I can't disagree since I haven't tried it. But I can say that I
don't really enjoy BASIC as a language. If you are in need of an
interpreted language, JAVA is better, and If you want a progrmming
language, pascal or c/c++ will be better. pascal for the ease of
learning, and c/c++ for the flexibility of pointers. And, if you want a
visual development that is easy, I'd go for Delphi, since Visual C isn't
very easy to get started with, and a visual java development probably
isn't what you want then.

(mina två ören.) <--My 2 öre.

-- 

//Spider 

( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Spider wrote:
> 
> Rudy Velthuis wrote:

> 
> > I've
> > however seen one example, where optimized Pascal code was *faster* than the
> > original hand-optimized assembler routine. This was also a string function.
> > It was the improved algorithm which did the trick.
> 
> Show me that pascal code, please.

I agree.  I'll bet real money that i can code any algorithm in asm
to run faster than a high level language. Although it's been 10 years
since
i've done my last 80386 device driver, i still occasionally have to slop 
my way stepping through optimized compiler output.  I am always
surprised
to see array indexes calculated with multiplys instead of shifts.
Also, C function calls always pay the price of building a stack frame.
push ebp ; mov ebp, esp ; is a very slow operation.  Stack operations
are slow, passing arguments in registers is much faster. In the case
of the 8080 and all of it's descendents, the chip is designed to have
specific arguments passed in specific registers.
Now pentiums are designed with dual pipelines and prefetch queues,
most of whose advantage is negated by constant test-branch logic.

On the other hand, i don't want to ever write assembler again.
I'd rather just buy a faster computer :)

* No problem is too large that a faster clock rate can't fix.

dik

Post a reply to this message

No and I hope, that POV team will use C or C++ or another portable
language.
There are two reasons:

1) Now I'am very long time waiting for UNIX version of POV.
     With parts in ASM it will take much more time to release this version.

2) Its imposible to write good optimized code for new processor such as
     PII or Merced because its internal structure is too complicated for
     human programmer. Good compiler can do much better this task.

Post a reply to this message

Spider schrieb in Nachricht <36D0602C.D635E4F6@bahnhof.se>...

>Rudy Velthuis wrote:
>>
>> Spider schrieb in Nachricht <36D01BE3.49F920CE@bahnhof.se>...
>>
>> >Show me that pascal code, please.
>>
>> If I can find it, I'll e-mail it to you. It was in one of the
>> news.inprise.com newsgroups (I think it was borland.objectpascal). It
should
>> have been deleted from my disk by now (I only keep newsgroup messages for
60
>> days), but I might have saved it somewhere (if I only knew where).
Otherwise
>> try Dejanews or the Delphi Super Page.
>Ah, I can try, If I knew what to look for... :-)

I've been looking in Gravity, but almost all my news was gone (I told you
about my self-imposed 60 day limit). I couldn't find it on Dejanews either.
But I'm 100% sure I've seen it somewhere.

>> But it was the improved algorithm which made the routine faster, not
Pascal
>> of course.

>I agree with you. but, often a specific algorthim is better than a
>general one, and most specific algorthims can be coded in asm once it is
>in a fast High level language. What I mean is that you gain less if you
>only trust that "asm is faster" and don't do a good algorithm first.
>Bubble-sort is faster in asm than in pascal, but still slower than
>ComboSort, SpeedSort or QuickSort. And theese algorithms would probably
>be faster in asm than in pascal. (Don't know, I haven't tried. I'm not
>_that_ interested in sorting speeds.)

Of course if you would implement a good algorithm in (good) assembler, you'd
propably gain some more speed. This can be done for simple algos. But to
optimize a huge program and rewrite it in assembler is not seeking for
speed, it is asking for trouble (bugs). Optimizers are not perfect, but
consistent. Humans are perhaps cleverer, but very inconsistent, make
mistakes, forget things, etc. Optimizers do not have these human traits.

>But I can say that I
>don't really enjoy BASIC as a language.

Neither do I, I'm a Delphi freak. And if, for some highly unimaginable
reason, I would have to dispose Delphi, I'd turn to C/C++. But those days,
BBC-Basic was all I had. It even taught me procedural programming, because
it had procedures and functions and local variables.

>(mina två ören.) <--My 2 öre.

How many Euro-Cents would that be?



--
//Spider
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Dick Balaska schrieb in Nachricht <36D0B79E.D5AF47B0@buckosoft.com>...
>Spider wrote:
>>
>> Rudy Velthuis wrote:
>
>>
>> > I've
>> > however seen one example, where optimized Pascal code was *faster* than
the
>> > original hand-optimized assembler routine. This was also a string
function.
>> > It was the improved algorithm which did the trick.
>>
>> Show me that pascal code, please.
>
>I agree.  I'll bet real money that i can code any algorithm in asm
>to run faster than a high level language.

Sure, so could I. But if the algo stinks, turning it into asm is not much
use either.

>I am always surprised
>to see array indexes calculated with multiplys instead of shifts.

Now I don't know of any good WIntel based 32bit compiler which wouldn't use
the *2, *4 indexing the x386 and higher offer, if optimizations are on.

>Stack operations are slow, passing arguments in registers is much faster.
In the case
>of the 8080 and all of it's descendents, the chip is designed to have
>specific arguments passed in specific registers.

Many C compilers can use register based passing of parameters nowadays.
Delphi's Pascal has it as a preset (but it has other calling conventions
too).

But the normal calling convention for dlls is still the stdcall convention,
which uses the stack.

>Now pentiums are designed with dual pipelines and prefetch queues,
>most of whose advantage is negated by constant test-branch logic.

I can't comment on that, but you'd propably need the Intel compilers to get
the most of them.

>On the other hand, i don't want to ever write assembler again.
>I'd rather just buy a faster computer :)

That's exactly what most programmers think - and they're more or less right.
Now, using RAD, and application frameworks and GUI frameworks etc., it is
impossible to fine tune everything using assembler. It's more combining
building blocks (mind you, I'm not saying that is not a skill - it certainly
is), and even the people writing the building blocks (the component writers)
hardly ever use assembler, unless for some tricky hardware access or some
tricky stack/register handling.

--
Rudy Velthuis

But the only thing I wrote was, that the Pascal algorithm displayed was
faster than the original string handling function written in assmbler. It
was the design which made it faster, not the fact it was written in
optimized Pascal (on the contrary). Propably converting this algorithm to
assembler would even make it (a bit) faster.

But for some applications and purposes, a rethinking of the algorithm will
do more than just converting everything to assembler. Especially a large app
like POV-Ray would be very hard to convert to assembler without introducing
millions of bugs. Optimizers still don't produce the best possible code (how
could they- they're way too general to do that), but they do their work also
on very large projects with the same quality. Humans can't do that.

Have a look at the dramatic speed improvements achieved in POV-Ray 3.1d for
some higher order objects (cubics, quartics, superelllipsoids, etc). I don't
think they suddenly turned to assembler, but they must have redesigned some
algorithms.

>* No problem is too large that a faster clock rate can't fix.

>dik

Post a reply to this message

Rudy Velthuis wrote:

> Have a look at the dramatic speed improvements achieved in POV-Ray 3.1d for
> some higher order objects (cubics, quartics, superelllipsoids, etc). I don't
> think they suddenly turned to assembler, but they must have redesigned some
> algorithms.
> 
> >* No problem is too large that a faster clock rate can't fix.
> 
> >dik

A word from Ken:

  Let's examine that speed improvement for just a moment. The items
in the scene were a quadratic spline using sturm, this had a 6 layer
semitransparent texture applied, and a hand full of superellipsoids.
  As I watched the scene render it was evident that the most time
consumed during the render operation was spent on the lathe object.
I would discount the superellipsoids from the speed improvement as
their addition to the render time was not much more than the other
versions.
  There is also the case where I simply used objects from shapesq.inc,
with and without sturm, that don't show near the increase in performance
you would expect as seen with the quadratic spline late object. While
there was improvement in general it wasn't on so high an order.
  There were also several bug fixes in this version and who is to say
what impact they may have had been having. I think the test data I
provided is good general indication of what can be expected as far as
increased performance from v3.1b and v3.1d. It only implies the reasons
the speed has been improved without disclosing why it is better.
  What were the contributing factors involved in this performance increase ?
I don't know, but the data should not have unsubstantiated value added
to it. What I presumed I was testing, and what the results indicate, may
be improperly assigned to the wrong attribute and should be taken into
consideration when examining the data.
  Obviously they have been reworking some of the code to make it ready
to become a full c++ compliant program (as mentioned in Chris Young's bug
fix report) and that may be what is adding to the performance. Without
direct knowledge of the changes and their implementation would be idle
speculation and not worthy of serious discussion.

My point is don't try to read too much into that data I provided because
it may be full of traps.

One more thing: Don't worry - Be happy.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Rudy Velthuis wrote:
<snippety> 


> 

> I've been looking in Gravity, but almost all my news was gone (I told y
ou
> about my self-imposed 60 day limit). I couldn't find it on Dejanews eit
her.
> But I'm 100% sure I've seen it somewhere.
ok :-) Thanx anyway.
 

> >> But it was the improved algorithm which made the routine faster, not

> Pascal
> >> of course.
> 

<snappety>  


> Of course if you would implement a good algorithm in (good) assembler, 
you'd
> propably gain some more speed. This can be done for simple algos. But t
o
> optimize a huge program and rewrite it in assembler is not seeking for
> speed, it is asking for trouble (bugs). Optimizers are not perfect, but

> consistent. Humans are perhaps cleverer, but very inconsistent, make
> mistakes, forget things, etc. Optimizers do not have these human traits
.
Yup, that Is what I have said in my own little way... or tried to
anyway..

I've never done anything more advanced in asm than to transform a
highoptimized pascal routine(screen melt thingy) into asm... lost a
helluva lot of procedure-calls, and the loop was far faster as well...
 

> >But I can say that I
> >don't really enjoy BASIC as a language.
> 

> Neither do I, I'm a Delphi freak. And if, for some highly unimaginable
> reason, I would have to dispose Delphi, I'd turn to C/C++. But those da
ys,
> BBC-Basic was all I had. It even taught me procedural programming, beca
use
> it had procedures and functions and local variables.
ok. I started in BASIC on a SVI computer. Then got on to turbo-pascal
4....
 

> >(mina två ören.) <--My 2 öre.
> 

> How many Euro-Cents would that be?
Hmm, I think it's something like 0,003-0,002. But I haven't looked at
the exchange rates.

-- 

//Spider 

( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message