POV-Ray : Newsgroups : povray.beta-test : Radiosity: status & SMP idea : Re: Radiosity: status & SMP idea Server Time
28 Jul 2024 20:25:04 EDT (-0400)
  Re: Radiosity: status & SMP idea  
From: nemesis
Date: 22 Dec 2008 11:50:01
Message: <web.494fc52bb480f792180057960@news.povray.org>
"Chambers" <ben### [at] pacificwebguycom> wrote:
> > -----Original Message-----
> > From: Warp [mailto:war### [at] tagpovrayorg]
> > Chambers <ben### [at] pacificwebguycom> wrote:
> > > Boost isn't slow.  Mutexing is slow (relatively).
> >
> >   Boost mutexes are actually the slowest I have tried, although not by
> > a
> > very large margin.
>
> > (interesting stuff about mutexing snipped)

Indeed. :)

> Yes, I'm aware of different designs for mutexes.  In fact, the fastest
> way to deal with them is to design your container such that they aren't
> even needed.  However, the only paper I've seen that said such a thing
> advocated using immutable state instead.
>
> That is, once a variable is created it cannot be modified.  In the case
> of a container, you don't actually change the container; you make a
> copy, set the reference to point to the modified data, and dump the
> original data.
>
> I was so impressed that I implemented a few tests of the idea just to
> get a feel for it.  It CAN be extremely fast, and threading CAN work
> effectively with it, but generally it's a pain in the a** and, if done
> wrong, you can screw up your data or get a big slowdown.

It's a pain in the ass to try to replicate functional programming in heavily
imperative languages, yes.  I'm sure Haskell would deal with it much more
gracefully. ;)


Post a reply to this message

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