POV-Ray : Newsgroups : povray.beta-test : PovRayUnofficial_3.8.0-alpha.9322209 for macintosh available : Re: PovRayUnofficial_3.8.0-alpha.9322209 for macintosh available Server Time
17 Jul 2024 12:45:05 EDT (-0400)
  Re: PovRayUnofficial_3.8.0-alpha.9322209 for macintosh available  
From: William F Pokorny
Date: 15 Oct 2017 11:39:59
Message: <59e3814f$1@news.povray.org>
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...


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

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

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

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