Le 23/05/2010 21:52, clipka a écrit :
> Am 23.05.2010 20:33, schrieb Alain:
> 
>> It would be good to remove at least one of those lines from
>> benchmark.ini:
>> Display=Off
>> This disable the preview.
>>
>> Output_To_File=Off
>> This disable saving the resulting image.
>>
>> As it is now, there is NO preview and the image is NOT saved anywhere.
> 
> This is by design. The benchmark is /only/ a benchmark of the render
> engine, and any output activity is /not/ part of what it should measure.

But, without calling it benchmark, it might be "interesting" to be able
to render the benchmark on screen and in a file (at the same resolution
as benchmark, same AA, same ...)
Maybe an additional offer ? (with some warning about timing being not
from benchmark)

-- 
A: Because it messes up the order in which people normally read text.<br/>
Q: Why is it such a bad thing?<br/>
A: Top-posting.<br/>
Q: What is the most annoying thing on usenet and in e-mail?

Post a reply to this message

Le_Forgeron wrote:
> the OS scheduler sucks if we still get a 2:1 ratio!)

It's well known that the Windows scheduler sucks if you mix interactive with 
compute-bound jobs. Especially at the same priority level. Almost as badly 
as it sucks with interactive vs I/O-bound jobs, but not quite.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

On 25/05/2010 2:29 PM, Le_Forgeron wrote:
> Now that's even stranger if the last is "without Task Manager running"!
> If it is "With Task Manager running", looks normal: more charge, more time!
>

Sorry for the confusion, it was 17m 31s without display and without the 
Task Manager running. 17m 40s without display and with the Task Manager 
running.

> Good news seems to be that display does not change the time with High
> Priority.
> Now, the question would be: does it (with display or without display)
> change the time when the priority is Low (as the default) ?

Do I see a volunteer? ;-)


-- 

Best Regards,
	Stephen

Post a reply to this message

Stephen <mca### [at] aolDOTcom> wrote:
> On 25/05/2010 2:29 PM, Le_Forgeron wrote:
Hello,

I tried 3.7 beta version, after serious problems with glass texture, media and
gamma, now I see that for several povray files the 3.7 SMP version is slower
than older 3.6 version (using only one core).
Hardware processor is core I7 870.

For core I7, the frequence is increased if you use only one core.

Did you saw something like this with the last POVRAY 3.7 SMP version.
With one povray file including glass texture, rendering time was 3 minutes using
3.6 single core and 12 minutes using 3.7 SMP.

Best regards,

JJ

Post a reply to this message

Le 09/08/2010 14:55, JJ a écrit :
> Stephen <mca### [at] aolDOTcom> wrote:
> Hello,
> 
> I tried 3.7 beta version, after serious problems with glass texture, media and
> gamma, now I see that for several povray files the 3.7 SMP version is slower
> than older 3.6 version (using only one core).

You are aware, of course, that some implementation have been changed ?

> Hardware processor is core I7 870.

Great, Could compare to mine then, if needed.

> 
> For core I7, the frequence is increased if you use only one core.
> 
> Did you saw something like this with the last POVRAY 3.7 SMP version.
> With one povray file including glass texture, rendering time was 3 minutes using
> 3.6 single core and 12 minutes using 3.7 SMP.

I'm lazy, I do not want to search for a scene with glass texture.

Can you name one for me from the distribution, so that I could test it ?
(especially one that displayed your reported behaviour: quick on 3.6,
slow on 3.7)

Thanks in advance.
(Ready to test with the latest beta, as soon as you name the scene file)

Post a reply to this message

Am 09.08.2010 15:08, schrieb Le_Forgeron:
> Le 09/08/2010 14:55, JJ a écrit :
>> Stephen<mca### [at] aolDOTcom>  wrote:
>> Hello,
>>
>> I tried 3.7 beta version, after serious problems with glass texture, media and
>> gamma, now I see that for several povray files the 3.7 SMP version is slower
>> than older 3.6 version (using only one core).

@Stephen: What OS and exact versions of POV-Ray are we talking about?


>> Did you saw something like this with the last POVRAY 3.7 SMP version.
>> With one povray file including glass texture, rendering time was 3 minutes using
>> 3.6 single core and 12 minutes using 3.7 SMP.

Such issues have already been reported a while ago with earlier POV-Ray 
3.7 betas, though mainly in conjunction with animations IIRC.

> I'm lazy, I do not want to search for a scene with glass texture.
>
> Can you name one for me from the distribution, so that I could test it ?
> (especially one that displayed your reported behaviour: quick on 3.6,
> slow on 3.7)
>
> Thanks in advance.
> (Ready to test with the latest beta, as soon as you name the scene file)

FYI: I'm currently running single-threaded (+WT1) beta.38 (inofficial 
64-bit binary compiled with Intel icpc 11.1) against a collection of 
~150 scenes on a Linux AMD64 machine (Phenom 9650 2.3GHz Quad-Core) to 
compare them with timing results for POV-Ray 3.6.1 (official 32-bit 
binary compiled with GNU g++ 3.4.1) and MegaPOV 1.2.1 (official 64-bit 
binary compiled with GNU g++, unknown compiler version).

If there's anything substantial about the single-thread timing issues, 
and those are /not/ OS- or compiler-dependant or specific to rare 
circumstances, then it should ring an alarm bell or two on my 
performance testbed.

So far, the tests have already highlighted a scene that renders in 8:35 
instead of 2:40 (MegaPOV), but that one uses radiosity, which has 
changed too much to be comparable.

Post a reply to this message

On 09/08/2010 4:08 PM, clipka wrote:
> Am 09.08.2010 15:08, schrieb Le_Forgeron:
>> Le 09/08/2010 14:55, JJ a écrit :
>>> Stephen<mca### [at] aolDOTcom>  wrote:
>>> Hello,
>>>
>>> I tried 3.7 beta version, after serious problems with glass texture,
>>> media and
>>> gamma, now I see that for several povray files the 3.7 SMP version is
>>> slower
>>> than older 3.6 version (using only one core).
>
> @Stephen: What OS and exact versions of POV-Ray are we talking about?
>

Christoph, are you writing to me? Or there maybe a cut and paste type 
error in the headers. Anyway I’m running Win 7 (32 bit) with Beta 38. 
The benchmark is the one under Render > Run Benchmark (all CPUs) with 
lots of other progs running. It took 9m 27s. Using 
"C:\Users\Stephen\Documents\POV-Ray\v3.7\scenes\advanced\benchmark.ini" 
took 34m 16s which is longer than what I reported previously/

-- 

Best Regards,
	Stephen

Post a reply to this message

Am 09.08.2010 19:19, schrieb Stephen:
> On 09/08/2010 4:08 PM, clipka wrote:
>> Am 09.08.2010 15:08, schrieb Le_Forgeron:
>>> Le 09/08/2010 14:55, JJ a écrit :
>>>> Stephen<mca### [at] aolDOTcom> wrote:
>>>> Hello,
>>>>
>>>> I tried 3.7 beta version, after serious problems with glass texture,
>>>> media and
>>>> gamma, now I see that for several povray files the 3.7 SMP version is
>>>> slower
>>>> than older 3.6 version (using only one core).
>>
>> @Stephen: What OS and exact versions of POV-Ray are we talking about?
>
> Christoph, are you writing to me? Or there maybe a cut and paste type

Oops, sorry. Should have been "@JJ:", as it turns out.

Post a reply to this message

On 09/08/2010 6:23 PM, clipka wrote:
> Am 09.08.2010 19:19, schrieb Stephen:

>> Christoph, are you writing to me? Or there maybe a cut and paste type
>
> Oops, sorry. Should have been "@JJ:", as it turns out.

That's what I thought :-P

-- 

Best Regards,
	Stephen

Post a reply to this message

Am 09.08.2010 17:08, schrieb clipka:

> If there's anything substantial about the single-thread timing issues,
> and those are /not/ OS- or compiler-dependant or specific to rare
> circumstances, then it should ring an alarm bell or two on my
> performance testbed.

I'm seeing notable slowdown for the following sample scenes (real 
run-time in seconds):

                 MegaPOV 1.2.1   3.7.0.beta.38 +WT1
chess2.pov      223             409
grenadine.pov   164		214
infinitybox.pov  16              34  (!!!)
wineglass.pov    40              58

(plus various scenes using radiosity, but I'm ignoring those here)

Except for the "chess2.pov" slowdown, the other three appear to have 
been newly introduced with beta.38, as a similar slowdown can also be 
observed between multi-thread beta.37a and beta.38 for these particular 
scenes.


OTOH, there is an even greater number of scenes exhibiting a notable 
(and in some cases astonishing) speedup, e.g.:

                         MegaPOV 1.2.1   3.7.0.beta.38 +WT1
glasschess.pov          499             281
landscape.pov           575              43  (!!!)
newdiffract.pov         574             129  (!!!)
projected_through.pov    36              13  (!!!)

(plus various scenes using radiosity, and others using crackle)

Again, some of these speedups can also be seen between multi-threaded 
beta.37a and beta.38.


 From this I draw the conclusion that the speed balance between 
individual features has indeed been changing, but the overall speed of 
POV-Ray has not degraded in that process.

Post a reply to this message