POV-Ray : Newsgroups : povray.binaries.images : Brute force rendering : Re: Brute force rendering Server Time
2 Aug 2024 04:22:25 EDT (-0400)
  Re: Brute force rendering  
From: Severi Salminen
Date: 16 Mar 2008 04:13:55
Message: <47dce4d3@news.povray.org>
I had a nasty bug which resulted tens of percents of system time when
doing a 2 thread rendering as opposed to single thread rendering.
(System time means that the CPU cycles are going somewhere else than to
the user process.)

It basically meant that the additional thread (using a Core 2 Duo)
didn't improve the rendering speed at all! And brute force rendering is
supposed to be very easy to make multi threaded.

The reason? The damn random number generator which wasn't thread safe! I
didn't realize that the 2 threads shouldn't access the same RNG. I found
this out after implementing Mersenne Twister and getting segfaults with
2 threads. For some reason the default rand() worked ok, but resulted
the speed loss. Now I give each thread their own RNG and my renderer
scales perfectly by the number of cores. Thread specific RNGs is better
than one shared RNG with mutexes as they slow things considerably down.

You can guess how much I now want the new Intel Q9300 or Q9450 ;-)

Here is a sample image. Basically identical to previous with some small
additions. This was also about a 8h rendering but bigger image and
almost twice the passes -> less noise.

I've also been cleaning and restructuring the code so that I can start
to implement more features. I also received the book I mentioned about.
It is invaluable source of information.


Post a reply to this message


Attachments:
Download 'kuva14.jpg' (111 KB)

Preview of image 'kuva14.jpg'
kuva14.jpg


 

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