Windows beta 7 is now available at http://www.povray.org/binaries/windows/beta.html.

As usual, the list of fixes is included in the install and is also viewable via
http://www.povray.org/binaries/windows/changes.txt.

This time, we have also made available, as a separate download, a VC++ compile of
the same code as is in the default install above. The purpose of this is twofold:

  1) If you find a bug in the intel compile (the default install), it is recommended
     that you see if the same thing happens with the VC++ compile. This will help us
     identify whether or not the problem is compiler-related.

  2) It allows you to better determine in what ways the intel compile is faster (or
     slower) than the VC++ compile.

NT/2K/XP users may want to note that the program will now print the used kernel and
user-mode CPU time at the end of each render. This is a more accurate way to determine
benchmark figures than measuring elapsed time.

-- Chris

Post a reply to this message

Used Kernel and User Mode CPU times are interesting but not very important.
At the end of the day (or days), it's the wall clock time that is the true
measure of how long the job took.

Jim

Post a reply to this message

Jim Kress wrote:

> Used Kernel and User Mode CPU times are interesting but not very important.
> At the end of the day (or days), it's the wall clock time that is the true
> measure of how long the job took.


I find it important as I am used to setting long renderings to a low 
priority and do other things during the render (read mail, news, 
experiment with quick scenes in Pov, ...). In this context, real cpu 
time will enable me to accuratly compare renderings.

Povingly,

Philippe

Post a reply to this message

"Jim Kress" <dea### [at] kressworkscom> wrote in message
news:3bde2b80@news.povray.org...
> Used Kernel and User Mode CPU times are interesting but not very important.

If you are attempting a benchmark, it is almost essential if you want a representative
result without having to lock your machine up during the render. Which is why it was
added.

[And in any case, why bother saying so ? Users could probably go through the UI and
pick
out a dozen features that are 'not very important', but they don't feel the need to
post
in a newsgroup about it ...]

-- Chris

Post a reply to this message

> [And in any case, why bother saying so ? Users could probably go through
the UI and pick
> out a dozen features that are 'not very important', but they don't feel
the need to post
> in a newsgroup about it ...]

Because I've seen other people duped into purchasing software that purports
to be 'faster' than other packages, based on cpu time.  However, after the
money is spent, these people find the wall clock time (i.e. the real time
that us humans actually observe) is worse than the other alternatives.  Not
a pleasant outcome.

Also, people need to be aware that actual, real world rendering time (i.e.
that time we humans actually live by) is wall clock time, not cpu time.  It
serves no good purpose to tell users "I rendered that image in 37 cpu
minutes" but not tell them "yeah it took 6 hours of real, human time"

I wasn't throwing stone.  I was just making sure people are aware of the
difference.

Jim


"Chris Cason" <newsadmin-despam-@povray-no-spam.org> wrote in message
news:3bde990b@news.povray.org...
>
> "Jim Kress" <dea### [at] kressworkscom> wrote in message
news:3bde2b80@news.povray.org...
> > Used Kernel and User Mode CPU times are interesting but not very
important.
>
> If you are attempting a benchmark, it is almost essential if you want a
representative
> result without having to lock your machine up during the render. Which is
why it was
> added.
>
> [And in any case, why bother saying so ? Users could probably go through
the UI and pick
> out a dozen features that are 'not very important', but they don't feel
the need to post
> in a newsgroup about it ...]
>
> -- Chris
>
>
>
>

Post a reply to this message

Jim Kress wrote:
> 
> [...]
> 
> Also, people need to be aware that actual, real world rendering time (i.e.
> that time we humans actually live by) is wall clock time, not cpu time.  It
> serves no good purpose to tell users "I rendered that image in 37 cpu
> minutes" but not tell them "yeah it took 6 hours of real, human time"
> 

That's a quite extreme example, but it's simply not the point.  When a
render takes 6 hours while 5 other people are using that computer and 3
large programs are running in background, that's meaningless.  What counts
concerning comparison is the bare computation power needed.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

> Also, people need to be aware that actual, real world rendering time (i.e.
> that time we humans actually live by) is wall clock time, not cpu time.  It
> serves no good purpose to tell users "I rendered that image in 37 cpu
> minutes" but not tell them "yeah it took 6 hours of real, human time"

... which is why the render time display still shows wall clock time, and the
CPU time display is hidden off in the message window (where, unless they choose
it instead of an editor window, most people will never see it).

it's also fair to point out that if the CPU time is significantly less than the
wall clock time, the user has a problem that's worth fixing. after all, if the
scene can render in 37 CPU minutes, but it took "6 hours of real, human time",
as you put it, then I think the user ought to be able to know this. Because it
shouldn't happen, and points to a major inefficiency in the OS or scheduler or
whatever. I don't think this should be hidden.

-- Chris

Post a reply to this message