Chambers <bdc### [at] yahoocom> wrote:
> I fully 
> expected multithreading to involve some overhead, making it slightly 
> slower on a single-processor machine

  A bit off-topic to this particular thread, but multithreading on a
single-processor computer does not necessarily mean slower execution
(even if by a really small margin). In fact, it may even mean slightly
faster execution.

  Multi-threaded applications which perform calculations and lots of
disk I/O might actually considerably benefit from multithreading even
in a single-processor computer. This is because while one thread is
waiting for disk I/O to complete, another thread can continue using
the CPU. With one single thread the process would be stuck during I/O.

  In a heavily CPU-oriented application such as POV-Ray you probably
won't get basically any speedup. The only case where there might be
a measurable difference is when rendering big animation frames which
render at a very high speed and which are saved in an uncompressed
file format (such as bmp).
  I'm not saying this is so (without actual measurements it's
impossible to say), but in theory it could be possible.

  So the problem you are experiencing is quite clearly related to
something else. Perhaps the new code has some big overhead in
recursive tracing calls? I can't say.
  However, since it's (most probably) nothing related to multithreading,
it can probably be fixed.

-- 
                                                          - Warp

Post a reply to this message

Chambers wrote:
> OK, here is a much simpler scene which demonstrates a similar speed 
> difference between 3.6 and 3.7.  Both again rendered on a P4 2.8 gHz, no 
> antialiasing, this time at 512x384.

thanks for the report, problems like this are one of the issues we still
need to chase down - fortunately it's just a bug and nothing fundamental
(there is no fundamental reason for 3.7 to be significantly* slower than
3.6, so in those cases where it is it's almost always either a bug or a
area that we haven't finished working on).

-- Chris

* there may be some areas that will show a slight slowdown on single-CPU
  non-hyperthreaded systems even once we've finished, as there were e.g.
  a number of places in the old code where shortcuts such as static caches
  were used that are incompatible with SMP operation, and in some cases
  the replacement may have more overhead. however we have some other plans
  to speed up the code elsewhere that ought to more than compensate for
  any such cases.

Post a reply to this message

>   A bit off-topic to this particular thread, but multithreading on a
> single-processor computer does not necessarily mean slower execution
> (even if by a really small margin). In fact, it may even mean slightly
> faster execution.
> 
>   Multi-threaded applications which perform calculations and lots of
> disk I/O might actually considerably benefit from multithreading even
> in a single-processor computer. This is because while one thread is
> waiting for disk I/O to complete, another thread can continue using
> the CPU. With one single thread the process would be stuck during I/O.

...which is, of course, the entire reason why multitasking operating 
systems were originally invented. :-)

Post a reply to this message

Chris Cason wrote:
> Chambers wrote:
>> OK, here is a much simpler scene which demonstrates a similar speed 
>> difference between 3.6 and 3.7.  Both again rendered on a P4 2.8 gHz, no 
>> antialiasing, this time at 512x384.
> 
> thanks for the report, problems like this are one of the issues we still
> need to chase down - fortunately it's just a bug and nothing fundamental
> (there is no fundamental reason for 3.7 to be significantly* slower than
> 3.6, so in those cases where it is it's almost always either a bug or a
> area that we haven't finished working on).

BTW, here is another scene which attempts to replicate the problem using 
reflection.  Not only does it show that reflection is not significantly 
slower in 3.7, in some cases reflection is even faster in 3.7 than 3.6! 
  So the bug is not directly related to recursive calls, but only to 
transmittance.

...Chambers

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Chambers wrote:
> BTW, here is another scene which attempts to replicate the problem using 
> reflection.  Not only does it show that reflection is not significantly 
> slower in 3.7, in some cases reflection is even faster in 3.7 than 3.6! 
>  So the bug is not directly related to recursive calls, but only to 
> transmittance.
> 
> ...Chambers

It gets even better.  I went back to the scene with the concentric 
spheres, and removed the IOR (so it's a bunch of transparent spheres, 
and nothing else).

Here are the old and new timings:

// Values using IOR
// Recursion 1: 1s; 4s; 4x
// Recursion 5: 2s; 15s; 7.5x
// Recursion 10: 4s; 29s; 7.25x
// Recursion 20: 9s; 1m 15s (75s); 8.3x
// Recursion 50: 37s; 5m 9s (309s); 8.35x

// Values NOT using IOR
// Recursion 1: 0s; 1s; -
// Recursion 5: 2s; 2s; 1x
// Recursion 10: 4s; 5s; 1.2x
// Recursion 20: 9s; 10s; 1.1x
// Recursion 50: 44s; 44s; 1x

As you can see, the 8x speed decrease is only observed when refraction 
(IOR other than 1.0) is used.  When no IOR is used, the speed is 
virtually identical.

...Chambers

Post a reply to this message

Chambers wrote:
> As you can see, the 8x speed decrease is only observed when refraction 
> (IOR other than 1.0) is used.  When no IOR is used, the speed is 
> virtually identical.

Ah, interesting. This is really useful information and will make tracking 
this down a lot easier. Thank you very much!!!

	Thorsten

Post a reply to this message

Chambers wrote:
> reflection.  Not only does it show that reflection is not significantly 
> slower in 3.7, in some cases reflection is even faster in 3.7 than 3.6! 
>   So the bug is not directly related to recursive calls, but only to 
> transmittance.

actually it was a bug in the dispersion code (it was kicking in when it
should not have).

try http://www.povray.org/temp/pvengine-icl-sse2.zip

-- Chris

Post a reply to this message

Chris Cason wrote:
> Chambers wrote:
>> reflection.  Not only does it show that reflection is not significantly 
>> slower in 3.7, in some cases reflection is even faster in 3.7 than 3.6! 
>>   So the bug is not directly related to recursive calls, but only to 
>> transmittance.
> 
> actually it was a bug in the dispersion code (it was kicking in when it
> should not have).
> 
> try http://www.povray.org/temp/pvengine-icl-sse2.zip
> 
> -- Chris

Thanks, much faster now.

...Chambers

Post a reply to this message

Chambers wrote:
> 1) The scene renders much too brightly in version 3.7

this is because display gamma correction is on by default in 3.7, and your
scene is designed for no correction. add a #version 3.6 or assumed_gamma 2.2
to your scene to avoid this issue (though it is better to change the scene to
look correct with gamma correction on since it will be more portable).

see the release notes for more information on the way gamma works now.

Post a reply to this message

"Chambers" <bdc### [at] yahoocom> wrote in message 
news:43e7ed94$1@news.povray.org...
> Go here:
> http://www.geocities.com/bdchambers79/pov_test/beta11c.html
>

For the record, I'm removing this page now.

...Chambers

Post a reply to this message