Since I haven't seen anyone else posting, I thought I'd post my own
completely non-rigorous observations. I just replaced my rev.1 266 MHz G3
with a 400 MHz (slow motherboard) G4.

Notes: The first number is the parse time, the second trace time, and the
third the total time. Parse+Trace=Total.

This was a 640x480 image, anti-aliased, 40 kb file buffer, and RAM
requirements set at 20437. The image consists of about 4000 spheres
graphing the Lorenz equation.

                                 Rev.1 266 G3   Rev.2 300 G3   Slow 400 G4
EXTENSIONS ON
Unofficial Compile                 9+163=172      8+ 43= 51     6+ 31= 37
Official Compile Normal Cache     23+172=195     20+154=174    16+118=134
Official Compile Largest Cache    24+177=201     20+151=171    16+118=134
EXTENSIONS OFF
Unofficial Compile                12+161=173     12+ 42= 54     7+ 31= 38
Official Compile Normal Cache     23+172=195     19+148=167    14+111=125
Official Compile Largest Cache    23+174=197     20+146=166    14+110=124



Observations: 

a) the unofficial compile is a lot faster than I thought it was in my home
configuration.

b) I hate this keyboard.

c) extensions on or off don't seem to make much difference--even though
extensions on also means VM on.

d) I hate this keyboard.

e) I keep meaning to write a graphing macro for POV :*)

f) The difference in parsing time *may* be because of the slowness of the
official compile in writing the vista buffers to the display. (The
unofficial may be writing them off-display; it certainly appears
instantaneous)

g) There doesn't seem to be much of any difference between the official
and unofficial compiles on the Rev.1 machine--at least, compared to the
big differences on the Rev.2 and G4!

h) the speed increase on the G4 vs. the Rev.2 machine appears to be
hovering right around 1/3 faster--which is just what you might expect from
the 400 MHz chip vs. a 300 MHz chip?

i) the mouse sucks, too.

===
#include "colors.inc"
#include "skies.inc"

camera {
   perspective 
   location < 0.0, 0.5, -25 >
   look_at < 0.5, 2, 1 >
}
light_source {
   < 10.0, 100, -100 >
   color rgb < 1.000000, 1.000000, 1.000000 > 
}
light_source {
   <20,100,10>
   color White
}
background  {
   color rgb < 1, 1, 1 > 
}

#declare wantCyl = 0;
#declare wantSweep = 1;
#declare wantObj = 2;
#declare theObj = sphere {<0,0,0>,.3}
#declare pointCount = 4000;
#declare pointDT = .01;
union {
/*sphere_sweep {
   linear_sphere_sweep
   pointCount+1
*/ //lorenz(<0,1,0>,4000,.06,.01,Blue,Green)
   lorenz(<0,1,0>,pointCount,theObj,pointDT,wantObj,Red,Green)
   pigment { color Green }
   rotate <0,-45,0>
   translate <10,0,0>
}

plane {
   y,-10
   pigment {
      color Blue
   }
   normal {
      ripples 3
      scale .2
      turbulence .2
   }
}

sky_sphere {
   S_Cloud2
   rotate <3,0,0>
}

#macro
lorenz(initialValues,iterationCount,lineRadius,dt,theType,startColor,endColor)
   /* Type 0: connected cylinders
      Type 1: linear sphere sweep
   */
   #local old_x = initialValues.x;
   #local old_y = initialValues.y;
   #local old_z = initialValues.z;

   #local colorDelta = color rgb <endColor.red-startColor.red,
      endColor.green-startColor.green,
      (endColor.blue)-startColor.blue>
   #declare colorDelta = colorDelta/iterationCount;
   
   #local dt2 = dt/2;
   #local i = 0;
   #switch (theType)
      #case (1)
         <old_x,old_y,old_z>,lineRadius
         #break
      #case (2)
         object { lineRadius
            translate <old_x,old_y,old_z>
            #if ((colorDelta.red != 0) | (colorDelta.green != 0) |
(colorDelta.blue != 0))
               pigment {
                  color startColor
               }
            #end
         }
         #break
   #end
   #while (i < iterationCount)
      #declare currentColor = startColor + colorDelta*i;
      #local d0_x = 10*(old_y-old_x)*dt2;
      #local d0_y = (-old_x*old_z + 28*old_x = old_y)*dt2;
      #local d0_z = (old_x*old_y - 8*old_z/3)*dt2;
      #local xt = old_x + d0_x;
      #local yt = old_y + d0_y;
      #local zt = old_z + d0_z;
      #local d1_x = (10*(yt-xt))*dt2;
      #local d1_y = (-xt*zt + 28*xt - yt)*dt2;
      #local d1_z = (xt*yt - 8*zt/3)*dt2;
      #local xt = old_x + d1_x;
      #local yt = old_y + d1_y;
      #local zt = old_z + d1_z;
      #local d2_x = (10*(yt-xt))*dt;
      #local d2_y = (-xt*zt + 28*xt - yt)*dt;
      #local d2_z = (xt*yt - 8*zt/3)*dt;
      #local xt = old_x + d2_x;
      #local yt = old_y + d2_y;
      #local zt = old_z + d2_z;
      #local d3_x = (10*(yt - xt))*dt2;
      #local d3_y = (-xt*zt + 28*xt - yt)*dt2;
      #local d3_z = (xt*yt - 8*zt/3)*dt2;
      #local new_x = old_x + (d0_x + d1_x + d1_x + d2_x + d3_x)/3;
      #local new_y = old_y + (d0_y + d1_y + d1_y + d2_y + d3_y)/3;
      #local new_z = old_z + (d0_z + d1_z + d1_z + d2_z + d3_z)/3;
      
      #switch (theType)
         #case (0)
            cylinder {
               <old_x,old_y,old_z>,<new_x,new_y,new_z>,lineRadius
               #if ((colorDelta.red != 0) | (colorDelta.green != 0) |
(colorDelta.blue != 0))
                  pigment {
                     color currentColor
                  }
               #end
            }
            #break
         #case (1)
            <new_x,new_y,new_z>,lineRadius
            #break
         #case (2)
            object { lineRadius
               translate <new_x,new_y,new_z>
               #if ((colorDelta.red != 0) | (colorDelta.green != 0) |
(colorDelta.blue != 0))
                  pigment {
                     color currentColor
                  }
               #end
            }
            #break
      #end
      #declare i = i + 1;
      #declare old_x = new_x;
      #declare old_y = new_y;
      #declare old_z = new_z;
   #end
#end

Post a reply to this message

In article <jer### [at] cerebusacusdedu> , jer### [at] acusdedu 
(Jerry) wrote:

> a) the unofficial compile is a lot faster than I thought it was in my home
> configuration.

Simply turn off the preview and measure again (see below), please!   Read
the official Mac documentation, please, please, please!

> f) The difference in parsing time *may* be because of the slowness of the
> official compile in writing the vista buffers to the display. (The
> unofficial may be writing them off-display; it certainly appears
> instantaneous)

You need to make sure both versions have the *same* settings!

Try the following: Make your settings in the official version, and also set
the "Write INI File" option in the Scene pane of the settings dialog.
Start the render (You don't need to let it finish).   After that you should
find a file with the extension ".ini" in the same folder as the scene file.

Now you have a correct set of settings for both versions:

Do use the INI file with the official version, just set the "Read INI File"
option in the Scene pane.

For the Smellenbergh unofficial version set the "Use INI file" option in the
"File & Path" pane and select the INI file.


> g) There doesn't seem to be much of any difference between the official
> and unofficial compiles on the Rev.1 machine--at least, compared to the
> big differences on the Rev.2 and G4!

This is obviously a setup error on your side. :-(

> h) the speed increase on the G4 vs. the Rev.2 machine appears to be
> hovering right around 1/3 faster--which is just what you might expect from
> the 400 MHz chip vs. a 300 MHz chip?

Yes, what did you expect? :-)


Also, a), and H) are ansered in the FAQ on the official Mac site:
<http://mac.povray.org/help_info.html#macfaq>


     Thorsten


NOTE: It is simply *impossible* that the unofficial compile (the one from
the Smellenberghs?) is anything faster than a few percent points simply
because there is *no* difference between the source code (except how the
preview is implemented) and *no* difference between compilers! All these
differences (if preview is off) are user setup errors, sorry!


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <37efffe5@news.povray.org>, "Thorsten Froehlich"
<tho### [at] trfde> wrote:

>In article <jer### [at] cerebusacusdedu> , jer### [at] acusdedu 
>(Jerry) wrote:
>
>> a) the unofficial compile is a lot faster than I thought it was in my home
>> configuration.
>
>Simply turn off the preview and measure again (see below), please!   Read
>the official Mac documentation, please, please, please!

Sorry, I was measuring this for my use (hence the "nonrigorous"
adjective). I always use the preview, so the relevant speed for me is with
preview on.

I no longer have the 233 to perform more testing.

>> f) The difference in parsing time *may* be because of the slowness of the
>> official compile in writing the vista buffers to the display. (The
>> unofficial may be writing them off-display; it certainly appears
>> instantaneous)
>
>You need to make sure both versions have the *same* settings!

Both were set to display the vista buffers. The unofficial compile seemed
to display them much faster--instantaneously, whereas the official compile
seemed to draw each box separately.

>> g) There doesn't seem to be much of any difference between the official
>> and unofficial compiles on the Rev.1 machine--at least, compared to the
>> big differences on the Rev.2 and G4!
>
>This is obviously a setup error on your side. :-(

That was my thought as well, so I ran that test twice; this was also the
reason I added the "extensions off" test, in the hopes that whatever was
causing the difference would not load. This was with the same POV settings
that I used on the G4 and on the Rev.2 G3. As you pointed out, I did not
use the same settings file for both compiles, but I did use the same
settings file across machines for each compile. When I get some G4s in our
lab, they'll be set up exactly the same as the rev.1 G3s in that lab; I'll
see if I can do some more rigorous testing when that happens.

>> h) the speed increase on the G4 vs. the Rev.2 machine appears to be
>> hovering right around 1/3 faster--which is just what you might expect from
>> the 400 MHz chip vs. a 300 MHz chip?
>
>Yes, what did you expect? :-)

Given your earlier explanation, exactly that :*)

>NOTE: It is simply *impossible* that the unofficial compile (the one from
>the Smellenberghs?) is anything faster than a few percent points simply
>because there is *no* difference between the source code (except how the
>preview is implemented) and *no* difference between compilers! All these
>differences (if preview is off) are user setup errors, sorry!

Yes, the one from the Smellenberghs. Do those differences make sense if
preview is on? I've occasionally turned preview off to get the greater
speed, and just can't handle it, especially for the long renders that
require the greater speed. I need to see what's going on!

I didn't actually switch to the unofficial compile for speed, I did so
because I need the Object Bounds patch for working with text. (In fact, I
had looked at the unofficial about a year ago, and decided against using
it; I prefer the less-cluttered interface on the official compile; but I
do a *lot* of work with text in POV, and really need the object bounds
patch, which was recently added.)

Jerry
http://www.hoboes.com/jerry/

Post a reply to this message

Thanks for your help. Have you seen the animation dedicated to you that I
posted in binaries.animations? I was hoping you'd reply something.

Post a reply to this message

In article <new### [at] cx38767-adt1sdcahomecom> , 
new### [at] hoboescom (Jerry Stratton) wrote:

> Sorry, I was measuring this for my use (hence the "nonrigorous"
> adjective). I always use the preview, so the relevant speed for me is with
> preview on.

Yes, I notice that. The problem is that we already get tons and tons of
reports their version would be faster, but its technically not possible
(without POV-Ray core source code changes), at least as far as I can see
(and it is so hard to explain/prove to users in non-tech terms; I am a  bit
upset by such claims and I am sorry if my reply sounded unfriendly!). On the
other hand, their frontend is completely different, but I know how to
"eliminate" that difference (for private testing)... and I am of course
aware of the slow preview. The thing is that i.e the official preview has no
size limit at all, you can preview images up to 32767 pixels in size, yet
3.5 will definetly improve speed and offer more options to tune it to a
maximum (over the current unofficial speed).

> I no longer have the 233 to perform more testing.

Well, I don't mind to just see the other results (G3/300 and G4/400) :-)

> Both were set to display the vista buffers. The unofficial compile seemed
> to display them much faster--instantaneously, whereas the official compile
> seemed to draw each box separately.

What you are seeing is the slow drawing into the preview image buffer by the
official version. QuickDraw does not support (prior to Mac OS 8.5 and even
there not officially!) image maps over 4095 pixels in size (true color) due
to some 16 bit values that use some upper bits for flags...so the current
official version works around it by creating a offscreen out of lots of
small parts. To draw to more than one part at a time requires a fair amount
of work for switching (you can reduce switching time that by increasing the
image buffer cache size in the prefs) as the buffer is also kept on disk (as
32K * 32K pixels are 4 GB in size!). And additionally, there are some extra
tricks neccessary for the alpha channel preview.

You can also speed up the official version preview a bit by switching to
below 100% magnification. This causes fewer (re)draws while rendering and
gives a small speedup.

> That was my thought as well, so I ran that test twice; this was also the
> reason I added the "extensions off" test, in the hopes that whatever was
> causing the difference would not load. This was with the same POV settings
> that I used on the G4 and on the Rev.2 G3. As you pointed out, I did not
> use the same settings file for both compiles, but I did use the same
> settings file across machines for each compile. When I get some G4s in our
> lab, they'll be set up exactly the same as the rev.1 G3s in that lab; I'll
> see if I can do some more rigorous testing when that happens.

It might also have to do with the preview. If Apple improved the graphic
card drivers (i.e. the single pixel drawing speed), it might be that you are
simply measuring that, or other screen related things. In general, try to
avoid all graphics when doing CPU speed tests, Apple does a lot to improve
on that part, and it messes up any benchmarks frequently :-(

> Given your earlier explanation, exactly that :*)

Yes, sad but true. Without AltiVec a G4 is just a slightly better G3. The
btter subsystem Apple builds around it is much more important.

> Yes, the one from the Smellenberghs. Do those differences make sense if
> preview is on? I've occasionally turned preview off to get the greater
> speed, and just can't handle it, especially for the long renders that
> require the greater speed. I need to see what's going on!

Yes, apparently a lot of people like to k.  If just anybody had reported
that during beta testing of 3.1 so we could have changed it ... :-)

> I didn't actually switch to the unofficial compile for speed, I did so
> because I need the Object Bounds patch for working with text. (In fact, I
> had looked at the unofficial about a year ago, and decided against using
> it; I prefer the less-cluttered interface on the official compile; but I
> do a *lot* of work with text in POV, and really need the object bounds
> patch, which was recently added.)

I am not sure what this patch does (I lost track of the hundrets of patches
out there :-) , but maybe it will be in 3.5.


     Thorsten


PS: When tring the INI file idea I suggested, generate the INi file with the
unofficial version. The official version eats that file, but the unofficial
one does not eat the one from the official version.


____________________________________________________
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

In article <37f034cd@news.povray.org> , "TonyB" 
<ben### [at] panamaphoenixnet> wrote:

> Thanks for your help. Have you seen the animation dedicated to you that I
> posted in binaries.animations? I was hoping you'd reply something.

No sorry, not yet, I don't check those groups frequently (at most once per
week)   :-)    But I will check out know, thank you!!!


    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:

> NOTE: It is simply *impossible* that the unofficial compile (the one from
> the Smellenberghs?) is anything faster than a few percent points simply
> because there is *no* difference between the source code (except how the
> preview is implemented) and *no* difference between compilers! All these
> differences (if preview is off) are user setup errors, sorry!
>
> ____________________________________________________
> Thorsten Froehlich
> e-mail: mac### [at] povrayorg
>
> I am a member of the POV-Ray Team.
> Visit POV-Ray on the web: http://mac.povray.org

Are ya'll using CodeWarrior? Version 5? Something else?

steve

Post a reply to this message

In article <38059455.166FA59E@puzzlecraft.com> , Steve 
<ste### [at] puzzlecraftcom>  wrote:

> Are ya'll using CodeWarrior? Version 5? Something else?

CW Pro 5 was not stable at the time of the release and had some nice bugs
preventing proper compilation of the offcial source. The version by the
Smellenberghs works around this by some quick hacks specific to these bugs.
The offcial source code is written to be cross-platform and we cannot do so
in an offcial version.  So the offcial version is compiled with CW Pro 4.1,
the latest stable version.  I have compiles with the current, stable CW Pro
5.2 (CW Pro 5.1 still had the bugs). Without preview the speed of the two
versions is then exactly the same while the currently available offcial
compile (3.1g.r1)is about 3% to 5% slower because of the different compiler
version - if the both versions are set up properly and with the _same_
options, of course.


    Thorsten


PS: The source code archive on mac.povray.org already contains projects for
CW Pro 5.x.


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message