POV-Ray : Newsgroups : povray.programming : SMP povray design? : Re: SMP povray design? Server Time
29 Jul 2024 02:33:15 EDT (-0400)
  Re: SMP povray design?  
From: Tim Hutcheson
Date: 25 May 1999 18:23:21
Message: <374b14c9.0@news.povray.org>
> Fix all of the global variables and other weirdness (like variable reuse)
> and then it would be a fairly easy task.

Agreed.

But usually you can find some low level which sacrifices generality and
elegance (but avoids the globals problem) in critical routines that can be
threaded to yield 90 percent of the performance improvement without doing a
full-up SMP design.  Kind of a thread-lite approach.  I have had some
surprising results with a little effort on routines that I thought were
impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
involved splitting the image work into two threads, synchronizing completion
and then doing a final pass to merge the results.  But it essentially
doubled the performance with two processors.

I have the source installed, what's a good candidate routine?

regards,

Tim Hutcheson
w4l### [at] bellsouthnet


Ron Parker <par### [at] fwicom> wrote in message
news:374b0039.0@news.povray.org...
> On Tue, 25 May 1999 14:48:58 -0500, Tim Hutcheson wrote:
> >Certain types of image processing routines are almost trivial to break
into
> >SMP threads under NT, especially if you can get all the performance from
> >just partitioning the image.  It can be done using only a thread control
> >structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
> >around the needed image processing routines.  Alternating scanlines is
> >better because it minimizes paging at the various cache levels.
> >
> >This doesn't give a very general solution but works great under NT and
the
> >code can run fine in Win98.  It only gets messy when the multiple threads
> >have to access the same data, that is, if the changes made by one thread
> >depend on the changes made by the other thread.  Then the synchronization
to
> >avoid exceptions destroys the performance or exception handling itself
> >becomes too complicated to manage.  If the core routines can be
individually
> >treated, that's where all the performance gain is anyway.
>
> Raytracing in general is very parallelizable.  It's just POV in specific
> that's a tough nut to crack, because the design did not anticipate
threading.
> Fix all of the global variables and other weirdness (like variable reuse)
> and then it would be a fairly easy task.


Post a reply to this message

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