From: Don Burns (don++at++andesengineering.com)
Date: 01/09/2006 15:30:59
I thought I should make a couple of comments here as Rick's descriptions are
close, but not quite accurate with respect with OSG's (rather Producer's)
approach to multithreading. I don't intend open a debate here as it would
not be appropriate, but I would encourage you to ask the question on the osg
list and I'll be happy to elaborate in great detail there.
For reference, this article was written during the design phase of Producer:
http://www.donburns.net/OSG/Articles/OSGMP/
and should shed some light on the the threading approach. It, in fact, does
a bit of a comparison between the two approaches.
As Rick mentioned, Performer's multiprocessing model is a superior one for
distributed shared memory. In a nutshell, processes duplicate both text and
data of executables, which allows a process' memory to be allocated close to
the local memory for a CPU. A thread which shares text and data cannot be
migrated in the topography to local memory with any level of determinism, so
often, during the execution of a thread, it may be fetching ops from
non-local memory. The tests we've done on Prism indicate that the level of
linearity in scalability is a toss of the dice from one run to the next.
There may be some tuning that can be done to improve this, but it would
require time on a prism.... that is, time on a prism with many CPUs and
pipes.... which is more than the author of Producer can afford right now.
Performer, to a lesser degree, suffers slightly from the same malady with
regard to the shared memory pool. However, this is data that is written to
with much less frequency than it is read and can be distributed nicely in
the memory architecture suffering performance only when data is written to
making invalidation on local copies necessary.
Consequently, the linearity in the simple case seems to be more
deterministic in a processing model Vs a threading model.
-don
On 1/9/06, Rick van Haasen <rick.van.haasen++at++philips.com> wrote:
>
> I have used both OSG and Performer on Onyx3400 (2-pipe IR4) and PC
> (Linux witn 2x Nvidia FX1400).
>
> my conclusion (until now) is as follows:
>
> -on Linux PC systems, using few CPU's and few graphic cards
> both Performer and OSG perform well. On Windows PC's OSG could
> run better because of multi-hreading (Performer doesn't support
> multi-processing on Windows).
>
> -on larger systems with many CPU's and graphic pipes (like SGI Onyx),
> Performer seems to do a better job.
>
> an architectural difference is the way multi-processing/multi-threading is
> done:
>
> Performer can use a pipeline that enables parallel processing of the app
> cull
> and draw stages, at the cost of max. 3 frames delay.
> while(1) {
> pfFrame();
> }
>
> OSG doesn't use a pipeline, but does everything within 1 frame period.
> while(1) {
> // Do the app stuff
> app();
> osgframe();
> }
> calling osgFrame() will trigger both the cull and draw threads.
> I have not looked how it is implemented but my guess is
> that it compares to what is called the DrawOverlappedCull mode in
> Performer,
> where a producer/consumer method is used to transfer the cull results to
> the draw thread. In that case, after being triggered, the draw thread has
> to wait for data being produced by the cull thread, which (at least in
> principle)
> is less efficient than the pipeline aproach.
>
> For OSG, the app() processing could also be done parallel to osgframe()
> by using a double buffer scheme, were one (or more threads) calculate data
>
> to be processed by osgframe() during the next iteration.
> Performer has the pfFlux object for this purpose.
>
> Performer further scales by using a set of (cull&draw) processes for each
> pipe.
> OSG uses a set of (cul&draw) threads for each camera.
> If you use for example (as in my case) 2 camera's per pipe, OSG will
> spawn
> more threads than i would like: each pipe can only be used by 1 draw
> process/thread
> at a time, so its better to let 1 process/thread sequentially process all
> camera's
> that are "mapped" to a pipe.
>
> Don Burns (OSG) mentioned a multiprocess/ multithread issue that has to do
> with
> the location of memory on Prisms (and probably to all shared memory SGI
> systems).
> The process aproach used by Performer will physicaly locate the memory
> more efficient than the thread aproach of OSG (more close tho the CPU that
> executes
> the process in a CPU locked system). This is more a "category of 10%
> performance"
> issue. Ask Don if you want to know more about this.
>
> A last issue is the opensource aspect of OSG. This is a big advantage of
> OSG,
> which results in an increasing number of plugins being developed,tested
> and debugged
> by the community.
>
>
> Rick.
>
>
>
>
>
>
>
>
>
>
> "Dorosky, Christopher G" <christopher.g.dorosky++at++lmco.com>
> Sent by:
> owner-info-performer++at++performer.engr.sgi.com
> 2006-01-04 21:32
>
> To
> Steve Satterfield <steve++at++nist.gov>
> Performer Mailing List <info-performer++at++sgi.com>
> cc
> John Kelso <kelso++at++nist.gov>
> Subject
> RE: [info-performer] Performer vs OpensScenegraph
> Classification
>
>
>
>
>
>
>
> I've used both.
>
> Here is the least controversial answer that I can give.
>
> Performer is closed source.
> OpenSceneGraph is open source.
> Performer has a longer history than OSG.
> Since Performer is closed source, they have dedicated some extra effort
> into the "helper" functions that do some complex tasks for you, because
> some of them would require in depth source knowledge to accomplish
> efficiently.
> OSG seems to lack some of this, but it is relatively young. At the same
> time, the C++ architechture of OSG is by far more robust than
> Performer's, although it's virtual class model isn't too shabby either.
>
> Performer seems to be more for someone who wants a rich set of
> functionality that already works, even if it isn't the most efficient
> example, whereas OSG is for people that want infinite expandability, and
> the power to change and understand all aspects of their program.
>
> Kinda like Performer = automatic transmission
> OSG = manual.
>
> Don't forget, Performer has a per-machine license, while OSG is free.
>
> Can't give you performance numbers, I never had a fair side by side
> test.
>
> Chris
>
> -----Original Message-----
> From: owner-info-performer++at++performer.engr.sgi.com
> [mailto:owner-info-performer++at++performer.engr.sgi.com] On Behalf Of Steve
> Satterfield
> Sent: Wednesday, January 04, 2006 1:31 PM
> To: Performer Mailing List
> Cc: Steve Satterfield; John Kelso
> Subject: [info-performer] Performer vs OpensScenegraph
>
> Has anyone done any comparisons between Performer and OpenScensGraph
> (http://www.openscenegraph.org/)?
>
> Our management is beginning to hear about OSG and expressing some
> interest in switching.
>
> I am assuming that Performer would run the best on the Prism
> architecture, but it would be good to hear some hard facts or
> experiences
>
> OSG is getting a lot of publicity and a growing following.
>
> What are your reasons for staying with Performer?
>
> What is the relative relative performance?
>
> What about in a multi-pipe/immersive environment?
>
> Thanks,
> Steve
>
>
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
>
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
>
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
>
This archive was generated by hypermail 2b29 : Mon Jan 09 2006 - 15:31:09 PST