Warp wrote:

> allocate and deallocate objects from the memory pool relatively
> infrequently. However, the more frequently they do it, the more likely
> it is that they will start obstructing each other, decreasing the overall
> performance of the program

However, if they do it frequently, one of the threads will always
be blocked. Using priorities will therefore prevent the situation
that thread 1 works at 100% and thread2 at 0%, and transform it
into thread 1 works at 50% and thread2 at 50%. While this is
better for responsiveness if one of the thread handles GUI
events or similar, it doesn't help overall performance for
parallelized number crunching as in POV-Ray.

An exception would be if thread 1 needs the lock often but
thread 2 only rarely. But I expect both threads to be doing
essentially the same task in parallel for speedup, so they
will also habe the same locking requirements.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> However, if they do it frequently, one of the threads will always
> be blocked. Using priorities will therefore prevent the situation
> that thread 1 works at 100% and thread2 at 0%, and transform it
> into thread 1 works at 50% and thread2 at 50%.

  Only in a 1-processor/single-core system.

  In a dual-core system the goal is to get as close to 100% and 100% as
possible. If the threads block each other from the resource, you'll get
100% and 0% (on the very extreme), so one of the cores will just sit
idle while the other does all the work.

  (Yes, it's quite unlikely to get to this extreme even with naive
mutexes, but in theory it's still possible. In practice you may still
get reduced efficiency in certain situations, and a FIFO would mostly
solve the problem.)

> An exception would be if thread 1 needs the lock often but
> thread 2 only rarely. But I expect both threads to be doing
> essentially the same task in parallel for speedup, so they
> will also habe the same locking requirements.

  Which is why it's important to distribute the resources to all
threads evenly.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   The reason why Boost is used is that it's portable to most systems.
> Pthreads can only be used in posix systems which implement it (if I'm
> not mistaken, most Windows compilers don't). OpenMP is a rather new
> standard and few compilers support it.

So maybe on Posix systems boost just wraps the Pthreads mutexes, thereby adding
some more overhead? Or is the difference much worse?

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote:
> Would it be faster if different threads rarely accessed the same locked
> data?  We could split the sample tree into several smaller trees
> (sub-trees, if you will) based on scene geography (grouping close
> samples in the same tree).  Then, when performing sampling, a thread
> would be most likely to only need access to a few of the sub-trees
> (those nearest), and rarely the sub-trees further away.  If you only
> have a few threads, then the chances of multiple threads needing the
> same sub-tree at the same time are minimized.  Having more threads would
> add more overhead, of course, because thread collision is more likely.

Doesn't work I guess. Think of an ordinary room: For most samples, you will need
samples from all across the room, not just a particular corner.

There may be scenes where your idea might speed up things, but in general
radiosity interaction between different parts of the scene can be expected to
be quite high.

The approach of subdividing an image, and feeding each part to a separate task,
works with regular raytracing only because even if parts of the scene interact
through reflection, there is no data cache being built and re-used - because
the chances of two mirrors showing exactly the same points are minimal (let
alone that even then the incident angles would be different) and so caching
wouldn't be worth the pain anyway.

Post a reply to this message

"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

"nemesis" <nam### [at] gmailcom> wrote:
> 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. ;)

As POV-ray is unfortunately(???) *not* programmed in Haskell, and most likely
will not be in near future, your point is a bit moot ;)

(I'd be a bit curious though to see how a Haskell-based raytracer would perform
overall, compared with POV 3.6 (C), or the current beta (C/C++ in every sense
of the slash)...)

I heard tell that Erlang is a good language to write distributed code, too...

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Presuming that having more samples than actually required is not an issue, then
> how about this one:
>
> [...]
>
> I'm also thinking about totally different approaches, although I can't see yet
> how they could be put to good use. One basic idea would be to have a single
> main pretracer thread that would find out what samples are needed, and have
> other threads actually collect them.
>
> One way this could be done would be as follows:
>
> [...]

Some serious feedback on this anyone, before it gets swamped in posts about
mutexes?

Post a reply to this message

Warp wrote:

>>However, if they do it frequently, one of the threads will always
>>be blocked. Using priorities will therefore prevent the situation
>>that thread 1 works at 100% and thread2 at 0%, and transform it
>>into thread 1 works at 50% and thread2 at 50%.
> 
>   Only in a 1-processor/single-core system.

Also on a dual-core system on worst-case locking (both threads
continually lock and unlock mutexes without doing anything else).
Admittedly not useful but also the only scenario when you get
thread 2 to really starve, which you initally worried about.

The only way to get both cores close to 100% is to minimize
the time spent in locked mutexes, so it becomes the exception
rather than the rule that on thread waits for the other. But
that works equally well with unprioritized mutexes.

Post a reply to this message

clipka <nomail@nomail> wrote:
> So maybe on Posix systems boost just wraps the Pthreads mutexes, thereby adding
> some more overhead? Or is the difference much worse?

  While Boost uses Pthreads in posix-compliant systems, according to my
tests its thin layer over it adds a tiny amount of overhead.

  OTOH I have also read somewhere that this small problem is (or is going
to be) fixed in newer versions of Boost by moving more code into inline
functions (thus effectively removing any overhead over calling Pthreads
directly).

  Anyways, overall it doesn't make too much of a difference. The basic
slowness of mutexes is the same.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> I heard tell that Erlang is a good language to write distributed code, too...

It's interpreted and dynamically typed, so it's certainly not something you 
want to try to write *fast* distributed code in. Erlang is distributed for 
reliability, not speed.  (And, FWIW, it's known to suck at floating point 
ops, too.)

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message