Yes, I'll commit to a commit.  This is certainly the sort of thing I'm
eager to get in there.  I wonder - is this only SGI, or all SMP-supported
platforms?

By way of explaining myself, I've been working on a fairly large change to
make the GNU-based builds work with the MSVC compiler on Windows.  I'm
doing this for two reasons.  First, it makes it possible to develop OpenDX
under MSVC, for those that are more comfortable in that environment.
Second, though, is the big one: that it will enable me to fold back in the
changes I've made to run the DX executive in native-windows mode.  This is
a big step forward, IMHO, because it supports ActiveDX (which will be going
into open source as soon as the native-OpenDX is in).  ActiveDX, in turn,
makes it possible to develop Windows applications that incorporate full
OpenDX functionality.
ActiveDX consists of a set of ActiveX components that are customized by
associating them with an OpenDX network, allowing you to create high-level
visualization components that can be used in any app that ActiveX
components are useful in - MSVC apps, Visual Basic...

While this has been going on, I haven't been too eager to incorporate
patches that involve changes to the configure/file header structure.    One
thing at a time.

Believe me, I'm working hard on it.  I suffered a bit of a setback when I
installed the newest Cygwin on my NT box - they seem to have messed up the
CRLF issues, making this a bit more painful than it should be.   The good
news is that select() is working a whole lot better.

Greg



Randall Hopper <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 05/31/2000
08:11:56 AM

Please respond to [email protected]

Sent by:  [EMAIL PROTECTED]


To:   [email protected]
cc:
Subject:  [opendx-dev] Re: dxexec: 20% perf speedup



Randall Hopper:
 |     From profiling dxexec, I've found that 20-25% of it's time in the
 |single-process case is spent locking and unlocking mutex locks (on SGI).
 |AFAICT these locks add unnecessary, avoidable overhead to the
 |single-process case.
 |
 |     I can cook a patch so that mutex locks are only used in dxexec when
 |"nprocs > 1".  But before I do, I'd like to find out whether the DX
 |committers would be willing to commit this patch.

Perhaps worth mentioning that I already have a patch and the 20-25% savings
is real savings, not estimated from prof numbers.  However the patch needs
refined to be ready for a commit.

--
Randall Hopper
[EMAIL PROTECTED]


Reply via email to