Copy-pase :-)
POV-Ray v3.7.1 has been redesignated v3.8.0, and we'll be back at alpha
stage for now.

http://megapov.inetart.net/povrayunofficial_mac/alphapov.html

--
Yvo

-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

I just ran a few comparisons with 3.7.0-unofficial for Mac.

The first test, a pretty simple model, seemed to run significantly faster on
3.8.0.  So I tried a quite complex model.  At quality level 9 but a 320x180
output to keep run time reasonable, I see the following:

3.7.0: 5:52 total, 2727 seconds trace time (8 threads), 741770 rays
3.8.0: 4:42 total, 1829 seconds trace time (8 threads), 786430 rays

So 3.8.0 is doing a bit more work (more rays, and the detailed work listing also
show more intersection tests etc.) but it does it substantially faster.

Naturally, I don't mind, but I thought it was curious, there's nothing I saw in
the changes list that suggests this is expected.   Could it just be a better
compiler?  3.7.0 mentions  Compiler: gcc 4.2.1 Compatible Apple LLVM 6.0
(clang-600.0.54) -- the 3.8.0 message window omits that information.

There is no obvious difference in the generated output images.

Post a reply to this message

Le 23/09/2017 à 11:50, E-mailyvo s gmx.net a écrit :
> Copy-pase :-)
> POV-Ray v3.7.1 has been redesignated v3.8.0, and we'll be back at alpha
> stage for now.

Great !


Small note : Preferences from 3.7.1_Beta8 are not resumed.



-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

On 2017-10-13 16:19:13 +0000, pkoning said:

> I just ran a few comparisons with 3.7.0-unofficial for Mac.
> 
> The first test, a pretty simple model, seemed to run significantly faster on
> 3.8.0.  So I tried a quite complex model.  At quality level 9 but a 320x180
> output to keep run time reasonable, I see the following:
> 
> 3.7.0: 5:52 total, 2727 seconds trace time (8 threads), 741770 rays
> 3.8.0: 4:42 total, 1829 seconds trace time (8 threads), 786430 rays
> 
> So 3.8.0 is doing a bit more work (more rays, and the detailed work 
> listing also
> show more intersection tests etc.) but it does it substantially faster.
> 
> Naturally, I don't mind, but I thought it was curious, there's nothing I saw in
> the changes list that suggests this is expected.   Could it just be a better
> compiler?  3.7.0 mentions  Compiler: gcc 4.2.1 Compatible Apple LLVM 6.0
> (clang-600.0.54) -- the 3.8.0 message window omits that information.
> 
> There is no obvious difference in the generated output images.

I see a completely different result, 3.8.0 is 5 to 6 times *slower* than 3.7.0.

Benchmark.pov scene with exactly the same settings:
3.8.0 >> 583,35 seconds
3.7.0 >> 114,76 seconds

Glasschess.pov scene:
3.8.0 >> 143,23 seconds
3.7.0 >>   23,85 seconds

A while back I noticed that 3.7.1 was a bit slower then 3.7.0 but not 
as extreme as the difference between 3.7.0 and 3.8.0

I verified the compiler options and I made no mistake there, optimized 
settings for release.

It would be good to know if the Windows or/and Linux version show the 
same difference between 3.7.0 and 3.8.0

BTW: your 3.7.0 version isn’t the latest, “r9” from august 2017 is the 
last version (compiler used is LLVM 8.1.0 (clang-802.0.42)):
http://megapov.inetart.net/povrayunofficial_mac/finalpov.html



--
Yvo

-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

On 2017-10-14 16:18:10 +0000, kurtz le pirate said:


>> Copy-pase :-)
>> POV-Ray v3.7.1 has been redesignated v3.8.0, and we'll be back at alpha
>> stage for now.
> 
> Great !
> 
> 
> Small note : Preferences from 3.7.1_Beta8 are not resumed.

That is no mistake, 3.8.0 is using new preferences!

-- 
Yvo

-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

Attachments:
Download 'iso-8859-1' (3 KB)

Yvo Smellenbergh <E-mail: yvo(DOT)s(AT)gmx.net> wrote:
>
> ...
> I see a completely different result, 3.8.0 is 5 to 6 times *slower* than 3.7.0.
>
> Benchmark.pov scene with exactly the same settings:
> 3.8.0 >> 583,35 seconds
> 3.7.0 >> 114,76 seconds

Yes, I see that too.  On my machine, 3.7.0 (the older version, I haven't
installed the correct one yet) took 200.4 seconds trace time, while 3.8.0 took
1118.9 seconds trace time.

The model I used for those earlier results is one with many simple objects
(about 19k of them), all but about 50 are opaque.

Post a reply to this message

On 10/14/2017 01:25 PM, E-mailyvo s gmx.net wrote:
> On 2017-10-13 16:19:13 +0000, pkoning said:
> 
> 
> I see a completely different result, 3.8.0 is 5 to 6 times *slower* than 
> 3.7.0.
> 
> Benchmark.pov scene with exactly the same settings:
> 3.8.0 >> 583,35 seconds
> 3.7.0 >> 114,76 seconds
> 
> Glasschess.pov scene:
> 3.8.0 >> 143,23 seconds
> 3.7.0 >>   23,85 seconds
> 
> A while back I noticed that 3.7.1 was a bit slower then 3.7.0 but not as 
> extreme as the difference between 3.7.0 and 3.8.0
> 
> I verified the compiler options and I made no mistake there, optimized 
> settings for release.
> 
> It would be good to know if the Windows or/and Linux version show the 
> same difference between 3.7.0 and 3.8.0
> 
> BTW: your 3.7.0 version isn’t the latest, “r9” from august 2017 is the 
> last version (compiler used is LLVM 8.1.0 (clang-802.0.42)):
> http://megapov.inetart.net/povrayunofficial_mac/finalpov.html
> 
> -- 
> Yvo
> 

I'm running 3.7.0 and 3.8.0 versions from early July. I see the 
following results for glasschess.pov which are in line with what we 
expect - a slight slowdown 3.7.0 to 3.8.0 and one which is a little 
worse when threads > cores; Excepting, where new intel/amd optimized 
noise is used (new to *nix compiles) and helps substantially. Where the 
new noise code helps we are usually faster - though with that code too - 
we have seen a few scenes coming in slower, but not run down why those 
particular ones slower with the new noise code.

I am running:

Ubuntu 16.04
g++ 5.4.0 20160609
i3-4130 CPU @ 3.40GHz

On what hardware are you guys running?

What happens if you use +wt<n> to run threads<=cores?

Note. These days timing is very sensitive to how the cache(s) on the 
system are being used when you do timing renders. 5-6x slower seems 
extreme for cache impacts. I've seen as much as about 2x slower on a 
busy system on occasion, but never more - and you are seeing similar 
across multiple renders...

glasschess.pov

3.7.0
-------------------
65.86user 0.03system 0:17.53elapsed  +wt4
65.97user 0.00system 0:17.53elapsed  +wt4
131.83

42.68user 0.02system 0:22.12elapsed  +wt2
42.68user 0.02system 0:22.12elapsed  +wt2
43.44user 0.02system 0:22.54elapsed  +wt2
128.8

3.8.0
-------------------
67.51user 0.04system 0:17.98elapsed +wt4
67.33user 0.08system 0:17.93elapsed +wt4
134.84  +2.28% slower

44.05user 0.04system 0:22.90elapsed +wt2
42.90user 0.04system 0:22.27elapsed +wt2
43.10user 0.02system 0:22.38elapsed +wt2
130.05  +0.97% slower

Perhaps related: Early this year - I think - Dick Balaska reported 
seeing much, much slower results for a 3.7.1 version on linux for frames 
of his animation hitting a certain linux machine in his collection of 
render machines.

Bill P.

Post a reply to this message

On 2017-10-15 15:39:59 +0000, William F Pokorny said:

> On 10/14/2017 01:25 PM, E-mailyvo s gmx.net wrote:
>> On 2017-10-13 16:19:13 +0000, pkoning said:
>> 
>> 
>> I see a completely different result, 3.8.0 is 5 to 6 times *slower* than 3.7.0.
>> 
>> Benchmark.pov scene with exactly the same settings:
>> 3.8.0 >> 583,35 seconds
>> 3.7.0 >> 114,76 seconds
>> 
>> Glasschess.pov scene:
>> 3.8.0 >> 143,23 seconds
>> 3.7.0 >>   23,85 seconds
>> 
>> A while back I noticed that 3.7.1 was a bit slower then 3.7.0 but not 
>> as extreme as the difference between 3.7.0 and 3.8.0
>> 
>> I verified the compiler options and I made no mistake there, optimized 
>> settings for release.
>> 
>> It would be good to know if the Windows or/and Linux version show the 
>> same difference between 3.7.0 and 3.8.0
>> 
>> BTW: your 3.7.0 version isn’t the latest, “r9” from august 2017 is the 
>> last version (compiler used is LLVM 8.1.0 (clang-802.0.42)):
>> http://megapov.inetart.net/povrayunofficial_mac/finalpov.html
>> 
>> -- 
>> Yvo
>> 
> 
> I'm running 3.7.0 and 3.8.0 versions from early July. I see the 
> following results for glasschess.pov which are in line with what we 
> expect - a slight slowdown 3.7.0 to 3.8.0 and one which is a little 
> worse when threads > cores; Excepting, where new intel/amd optimized 
> noise is used (new to *nix compiles) and helps substantially. Where the 
> new noise code helps we are usually faster - though with that code too 
> - we have seen a few scenes coming in slower, but not run down why 
> those particular ones slower with the new noise code.
> 
> I am running:
> 
> Ubuntu 16.04
> g++ 5.4.0 20160609
> i3-4130 CPU @ 3.40GHz
> 
> On what hardware are you guys running?
> 
> What happens if you use +wt<n> to run threads<=cores?
> 
> Note. These days timing is very sensitive to how the cache(s) on the 
> system are being used when you do timing renders. 5-6x slower seems 
> extreme for cache impacts. I've seen as much as about 2x slower on a 
> busy system on occasion, but never more - and you are seeing similar 
> across multiple renders...
> 
> glasschess.pov
> 
> 3.7.0
> -------------------
> 65.86user 0.03system 0:17.53elapsed  +wt4
> 65.97user 0.00system 0:17.53elapsed  +wt4
> 131.83
> 
> 42.68user 0.02system 0:22.12elapsed  +wt2
> 42.68user 0.02system 0:22.12elapsed  +wt2
> 43.44user 0.02system 0:22.54elapsed  +wt2
> 128.8
> 
> 3.8.0
> -------------------
> 67.51user 0.04system 0:17.98elapsed +wt4
> 67.33user 0.08system 0:17.93elapsed +wt4
> 134.84  +2.28% slower
> 
> 44.05user 0.04system 0:22.90elapsed +wt2
> 42.90user 0.04system 0:22.27elapsed +wt2
> 43.10user 0.02system 0:22.38elapsed +wt2
> 130.05  +0.97% slower
> 
> Perhaps related: Early this year - I think - Dick Balaska reported 
> seeing much, much slower results for a 3.7.1 version on linux for 
> frames of his animation hitting a certain linux machine in his 
> collection of render machines.
> 
> Bill P.

Tanks for your report!
The slowdown is related to the new compiler version (Xcode 9), somehow 
the compiler isn’t optimizing the code for this project.

I’ll revert back to Xcode 8 until I know what is causing this.

-- 
Yvo

-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

Post a reply to this message

Attachments:
Download 'utf-8' (7 KB)

On 10/15/2017 11:39 AM, William F Pokorny wrote:
> On 10/14/2017 01:25 PM, E-mailyvo s gmx.net wrote:
> 
> Note. These days timing is very sensitive to how the cache(s) on the 
> system are being used when you do timing renders. 5-6x slower seems 
> extreme for cache impacts. I've seen as much as about 2x slower on a 
> busy system on occasion, but never more - and you are seeing similar 
> across multiple renders...
> 

Off doing other things when I remembered years ago I did have a 
situation where my other than trivial renders were running many times 
slower than expected. My CPU fan had clogged & died unknown to me and my 
Intel i7 throttled the CPU frequency back substantially to where it was 
running right at the TDP temperature. Modern CPUs do this slow down 
thing so as not to cook themselves. Older CPUs sometimes do not and I 
know folks here have fried such CPUs with POV-Ray renders in the past.

The turbo feature of many CPUs complicates timing too - my i3 doesn't 
have it.

Anyway, suppose just an off the wall thought maybe these huge slow downs 
are due temperature and self throttling CPUs. Though that would mean 
3.8.0 code runs hotter than the 3.7.0 code and enough so that the CPU 
throttles down. A long shot reason I suppose, but the 5-6 slower seems 
so out there given some of what you ran was faster. The -32% faster is 
quite large for a 3.7 to 3.8 improvement from what I've seen that was 
faster.

Bill P.

Post a reply to this message

On 10/15/2017 12:46 PM, E-mailyvo s gmx.net wrote:
> 
> Tanks for your report!
> 
> The slowdown is related to the new compiler version (Xcode 9), somehow 
> the compiler isn’t optimizing the code for this project.
> 
> 
> I’ll revert back to Xcode 8 until I know what is causing this.
> 
> 
> --
> 
> Yvo
> 

Glad you found the cause! :-)

Bill P.

Post a reply to this message