On 2017-03-09 23:07-0800 Alan W. Irwin wrote:
[...]
> In sum, I believe we need to make the two improvements above (solve
> the wxPLViewer order of magnitude inefficiency issue and display
> wxPLViewer plots immediately for each part of plbuf that is received)
> before we can get believable timing results. Therefore it is much too
> soon to judge any of the "IPC3 unnamed semaphores", "IPC3 named
> semaphores", and "IPC single mutex" approaches based on any apparent
> timing issues that are occurring now, and once we get more reliable
> timing my guess is we will see no important difference in timing
> results between the three different IPC methods that are currently
> implemented.
To Phil and Pedro:
I finally figured out a way to substantially reduce how the wxPLViewer
app was interfering with timing measurements for -dev wxwidgets!
To work around the wxPLViewer rendering inefficiency problem mentioned
above, I ensured nothing is rendered by that app by making a local
modification of utils/wxplframe.cpp to #define the PLPLOT_WX_NOPLOT
macro. (See commit 7cfd6ce to see exactly the few lines of code that
are skipped when that local modification is made). To work around the
uncertainty about what the -np option is actually doing, I don't use
that option for my timing tests (see the command below). Finally,
(although I am not sure this makes much difference but I state this
for the record) I also used a minimal desktop (fvwm) rather than KDE
to vastly reduce the number of background desktop tasks that are
contending for the cpu and memory when doing timing tests. So for a
given CMake configuration, and after setting
export TIMEFORMAT=$'real\t%3R'
to use a one-line real time difference format for time results, a
timing run is done using the following command
(for N in $(seq --format='%02.0f' 0 34 |grep -vE '20'); do
echo $N; examples/c/x${N}c -dev wxwidgets >&/dev/null; killall
-9 wxPLViewer; (time examples/c/x${N}c -dev wxwidgets >&/dev/null); killall
-9 wxPLViewer ; done) >| <captured results file> 2>&1
where the name of the <captured results file> depends on the
configuration being tested to keep the results conveniently separated.
Within that command, I run each of the 34 (!) examples twice so that the
second timed run will be done with cached memory results. After each
example completes I kill the corresponding wxPLViewer instance because
there is a slight bug with the PLPLOT_WX_NOPLOT macro such that it
leaves an empty wxPLViewer GUI rather than properly terminating that.
With the above procedure I now have reasonable timing consistency.
For example, timing results differ for a given example
by a maximum of 13 ms from one run of the above command to the next
for identical configurations.
For the -DPL_WXWIDGETS_IPC3=ON case if I compare results derived from
the above command for both named and unnamed semaphores, the
differences are within the 13 ms noise of the time measurement. That
is an important result which means that eventually in the interests of
simplifying our code (and because unnamed semaphores are not
universally available on all platforms) we will likely want to remove
the unnamed semaphores variant and retain the named semaphores variant
of the 3-semaphores approach, i.e., drop all code that currently is
only compiled when the PL_HAVE_UNNAMED_POSIX_SEMAPHORES macro is
#defined.
If I compare results derived from the above command for
-DPL_WXWIDGETS_IPC3=ON (three semaphores approach) versus
-DPL_WXWIDGETS_IPC3=OFF (one mutex, circular buffer approach), I get the
following result from ndiff (where the -abs 0.100 option
ignores absolute time difference less than 100 ms, "ON_OFF" refers
to results collected with -DPL_WXWIDGETS_IPC3=ON
-DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=OFF, and "OFF" refers to results
collected with -DPL_WXWIDGETS_IPC3=OFF):
ndiff -abs .100 ../IPC3_timing_ON_OFF_alt11.txt ../IPC3_timing_OFF_alt11.txt
16c16 example 07
< real 0.392
--- field 2 absolute error 1.14e-01
> real 0.506
30c30 example 14
< real 0.521
--- field 2 absolute error 1.42e-01
> real 0.379
36c36 example 17
< real 10.474
--- field 2 absolute error 1.65e-01
> real 10.309
54c54 example 27
< real 0.292
--- field 2 absolute error 1.11e-01
> real 0.403
66c66 example 33
< real 1.543
--- field 2 absolute error 1.07e+00
> real 2.610
### Maximum absolute error in matching lines = 9.00e-02 at line 8 field 2
The above results mean the three-semaphores IPC approach is more
efficient than the single mutex + circular buffer IPC approach for 3
out of these 5 examples (i.e., 60 per cent of the examples) with
differences > 100 ms. However, if I had printed out all differences
greater than the maximum timing noise of ~13 ms that fraction drops to
~20 per cent.
Of course, for multiple cpu hardware (such as my two-cpu PC), circular
buffers do have a general speed advantage in ideal circumstances since
one cpu can be writing to the buffer with -dev wxwidgets and the other
cpu can be reading from that buffer with wxPLViewer. Whereas with the
three semaphores approach writing to the buffer is blocked while it is
being read from and reading from the buffer is blocked while it is
being written to. So that is a factor of two advantage to circular
buffers in ideal circumstances for multiple cpu hardware. However,
there are some additional overheads with the circular buffer approach
(such as timing loops and checks that reading is not getting ahead of
writing) which it appears under certain circumstances (i.e., 60 per
cent of the large difference examples and 20 per cent of all examples)
are larger than that theoretical saving.
Of course, in general, IPC takes a relatively small time to complete
compared to the rendering cost (e.g., example 33 with more than 100
pages takes only a few seconds for IPC) so I believe the above
differences in IPC cost are not that important in the grand scheme of
things. So I suggest (based on the much more important factor of code
clarity) that eventually (say, once you guys have dealt with the issue
with the -locate option for example 1) we should use the three named
semaphores IPC approach exclusively (by forcing the PL_WXWIDGETS_IPC3
macro to always be #defined and the PL_HAVE_UNNAMED_POSIX_SEMAPHORES
macro to always be #undefined). And once we are completely happy with
that configuration (and presumably before the next release) we should
follow up by doing a massive code cleanup to drop the code that is
ignored when we use those forced settings.
Please do fix the -locate issue and evaluate the code clarity for
yourself for the case when PL_WXWIDGETS_IPC3 is #defined and
PL_HAVE_UNNAMED_POSIX_SEMAPHORE #undefined sooner rather than later.
N.B. The reason why I am emphasizing "sooner" is it is important to
deal with such issues relatively early in this release cycle rather
than in some last-minute rush before a release when our judgement will
likely be impaired by release stress. Also, I am extremely familiar
with the -DPL_WXWIDGETS_IPC3=ON version of the code now so I can
easily answer your questions about it while that won't be as much the
case later. So your attention to these wxwidgets requests from me as
soon as you have any spare time at all would be much appreciated!
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
