POV-Ray : Newsgroups : povray.macintosh : pov 3.5 : Re: pov 3.5 Server Time
1 Jun 2024 15:49:44 EDT (-0400)
  Re: pov 3.5  
From: WhiteGandalf
Date: 16 Jul 2002 17:02:02
Message: <20020716230156187+0200@news.povray.org>
In <chr### [at] netplexaussieorg> Christopher 
James Huff  wrote:
> You forgot to take the compiler into account...the version of gcc in 
> the  development tools is nowhere near as good at optimization as 
> Metrowerks  CodeWarrior (which is used for the official version). The 
> next update of  the development tools will use a more up to date 
> version of gcc which is  apparently much better at optimization of PPC 
> code, I don't know how it  compares to CodeWarrior. If you want to 
> compare 3.1 and MegaPOV, compile  MegaPOV with gcc as well.

This exaclty was the point. I used gcc and complained about it!

> And anyway, being a GUI program won't really affect the render 
> speed...you probably ran the command line version from Terminal.app, 
> which (obviously) is a GUI program itself. The only way there could be 
> a  significant difference is if you booted up without any GUI at all, 
> which  I don't consider worth the few % of CPU time gained. Just being 
> a CLI  program doesn't give any special advantages.
Well, that's not completely true, after all without preview povray isn't 
doing much.
Specifcally I run my CLI compile both in terminal.app and then i booted 
console only. Appple did a fine work, no noticeable difference (under 1%). 
This of course if you leave the GUI in peace, if you move windows around 
it isn't fair.
Being a CLI program shouldn't give any significant advantages during 
render, but it was one way to test gcc from orignal sources.

And I must add, CodeWarrior, at least the older versions, isn't such a 
speedy compiler. Under os classic where MPW was available it was 
consistently outperformed as T. Fr?hlich will remind. He sent me an 
unofficial MPW compile and it was quite faster.


> There may be something specific to how POV-Ray Mac works though...
> maybe  the way it handles events uses up CPU time or prevents it from 
> using  100% of available cycles.
strictly speaking "cycles" doesn't make much sense in a unix environment. 
It is not a single program that decides to acquire or release the CPU 
but the kernel.

-ric-


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.