Ken wrote:
> 
> POV-Win experienced a performance increase between the two but I wouldn't
> call it a "big" jump. Version differences in POV-Ray itself had a greater
> impact than the compiler did. See my report in povray-FAQ group :)

It was big enough to allow POV-Win to leapfrog over povray on Linux on
identical Pentium-II hardware.  I rendered skyvase.pov (I forget the
exact settings) with 3.1d on WinNT in 349 seconds and povray 3.1e on
Linux in 388 seconds.  I don't have figures for how 3.02 performed.

-Mark Gordon

Post a reply to this message

What kind of speed difference are you seeing?  Are you sure your
comparing apples to apples?  i.e. different anti-aliasing levels on the
two OS's.  One thing I've noticed is that x display of X-pov can be very
slow,  especially if it must convert the preview image to a small color
pallet (8 or 16 bit color depth).   Try rendering with the display off
"-d".  If you see a significant speedup, this is your problem.  Make
sure you are in a true color video mode (24 bit or better)  or just skip
the preview and wait for the TGA file.

dave


Edward Coffey wrote:
> 
> OK, so I'm pretty new to all this Linux jazz - but why is my newly-compiled
> X-POV so very much slower than POV-Win?  I compiled it with the
> optimisations appropriate for my machine, what can I do to make it faster?
> (Machine: Pentium-Pro 200MHz, 32Mb ram, RedHat Linux 6.0)

-- 
David Tucker
dav### [at] altatechcom
http://www.altatech.com/

Post a reply to this message

Edward Coffey wrote:
> 
> OK, so I'm pretty new to all this Linux jazz - but why is my newly-compiled
> X-POV so very much slower than POV-Win?  I compiled it with the
> optimisations appropriate for my machine, what can I do to make it faster?
> (Machine: Pentium-Pro 200MHz, 32Mb ram, RedHat Linux 6.0)

	As you may have read by now, mine is a bit (10% or so) faster than
the Windows MSVC++ compile. There's no telling why, not from me
anyway. The only real difference that I can see in my installation
from yours is that I used the pre-compiled version "povlinux.tgz".
It says in the Readme that it was compiled with some "fastmath"
switch on. Is that the explanation ? Well maybe. 
	
	If you want to try the pre-compiled version just tar -zxvf it in
/usr/local/lib/ and it will install all by itself. Then just move or
copy files like the man page "povray.1" and .povrayrc as said in the
Readme. Also check for the right libraries for X and svga to be
there (I think that 6.0 has them but...)

	Hope this help.

	If I went into too much details forgive me : I personnally hate
when "the obvious is assumed". 

	Have fun.

	Jean

Post a reply to this message

Mark Gordon wrote:
> 
> Edward Coffey wrote:
> >
> > OK, so I'm pretty new to all this Linux jazz - but why is my newly-compiled
> > X-POV so very much slower than POV-Win?  I compiled it with the
> > optimisations appropriate for my machine, what can I do to make it faster?
> > (Machine: Pentium-Pro 200MHz, 32Mb ram, RedHat Linux 6.0)
> 
> I've made the same observation.  My guess is that gcc doesn't optimize
> for Pentium II as well as MSVC++ does.  POV-Win experienced a big
> performance jump in moving from Watcom to MSVC++.
> 

The standard makefile for PoV does not optimise for any particular
version of 
the x86 so adding a -mpentiumpro might be a good thing to do, it might
add some
extra speed due to the specification to (e)gcc that it's safe to do some
things,
that "normal" pentiums doesn't understand.

note, I haven't done this myself, but it should be safe, since we are
using -O6.

/Peter Toneby

Post a reply to this message

Ken Matassa wrote:

> Jon A. Cruz wrote:
> ...snip...
>
> >... For example, my computer has a Proimise-66 ultra DMA controller, but the
drivers I'm running on under Linux are only tweaked for ultra-33 performance.
>
> ...snip...
>
> I was under the impression that Linux didn't support the ultra-66
> standard. Is it working because of the way you have your drives
> configured or what?
>
> Ken Matassa

Well, Linux on RH 6.0 with the 2.2.5 kernel supports the Ultra-33 DMA as long as the
install gets told the parameters. Also, Ultra-66 seems backwards
compatible with Ultra-33. I hear that the newer kernels handle Ultra-66.

I have a Promise Ultra-66 controller with my only hard-drive on it. The motherboard
IDE is not used except for CD and ZIP.


--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Thanks for the info. I've been wanting to build a new system, and was
concerned because the boards I've been looking at most have onboard
Ultra_66. Now I can go ahead and build.

Ken Matassa

Post a reply to this message

> The standard makefile for PoV does not optimise for any particular
> version of
> the x86 so adding a -mpentiumpro might be a good thing to do, it might
> add some
> extra speed due to the specification to (e)gcc that it's safe to do some
> things,
> that "normal" pentiums doesn't understand.

Yeah, did that already.

Post a reply to this message

> What kind of speed difference are you seeing?  Are you sure your
> comparing apples to apples?  i.e. different anti-aliasing levels on the
> two OS's.  One thing I've noticed is that x display of X-pov can be very
> slow,  especially if it must convert the preview image to a small color
> pallet (8 or 16 bit color depth).   Try rendering with the display off
> "-d".  If you see a significant speedup, this is your problem.  Make
> sure you are in a true color video mode (24 bit or better)  or just skip
> the preview and wait for the TGA file.

I was careful to use exactly the same settings for both renders - I had the
preview turned on for both, but I will try it without to see if this brings
them in line.

Post a reply to this message

Jean Montambeault wrote:
> 
> Edward Coffey wrote:
> >
> It says in the Readme that it was compiled with some "fastmath"

	what is this 'fastmath'  ?

-- 
            ----------------------------------------------
	   <  tonton Th  /  Thierry Boudet  /  Mr Oulala  >
	    ----------------------------------------------

Post a reply to this message

Tonton Th wrote:
> 
> Jean Montambeault wrote:
> >
> > Edward Coffey wrote:
> > >
> > It says in the Readme that it was compiled with some "fastmath"
> 
>         what is this 'fastmath'  ?
> 
> --
>             ----------------------------------------------
>            <  tonton Th  /  Thierry Boudet  /  Mr Oulala  >
>             ----------------------------------------------
	"-ffast-math" is the right spelling. It is a switch for the gcc
compiler. It is non-ANSI. It optimizes the code for speed in math
calculation by using tricks like assuming that you won't try to find
sqrt(negative_number) for an example.

	Jean

Post a reply to this message