Also also I forgot to say, the gcc driver does not appear to get built by
default on my system. Do I have to manually enable it?
-----Original Message-----
From: "Phil Rosenberg" <p.d.rosenb...@gmail.com>
Sent: 02/01/2016 16:34
To: "Phil Rosenberg" <p.d.rosenb...@gmail.com>; "Alan W. Irwin"
<ir...@beluga.phys.uvic.ca>; "PLplot development list"
<Plplot-devel@lists.sourceforge.net>
Subject: RE: Linux wxwidgets inefficiency not solved
Also, i forgot to say, the following command
time ./x20c.exe -dev null -np
Gives a real time of ~12 s too.
From: Phil Rosenberg
Sent: 02/01/2016 16:28
To: Alan W. Irwin; PLplot development list
Subject: RE: Linux wxwidgets inefficiency not solved
Hi Alan
I have reproduced your timings on windows with the command
time ./x20.exe -dev wxwidgets -np. This gives me a similar ~23s real time and a
fraction of a second user and sys time. Note that this is run from Cygwin bash
shell, but x20.exe is built using visual studio.
I tried quite hard to locate the source of the delay. There are a few sleep
calls while I have to wait for the viewer.
I tried the following tests to try to isolate the problem. With every wxWidget
driver callback returning immediately so the driver does nothing, I still get a
real time of ~5s. So even when the wxWidgets driver does nothing there is still
some unaccounted for time.
If I allow initialisation to occur the real time jumps to ~12 seconds. This
presumably involves some time waiting for the viewer to initialise and for the
shared memory to be allocated.
Allowing everything other than getting the size of text ups the time to around
15s.
Enabling getting text size ups the total to 23s again.
So on my system I seem to have the following approximate timing breakdown
5s plplot core
7s wxViewer initialisation
8s getting text size
3s everything else wx related
The reason getting text size takes so long I that it requests the size from the
viewer and that two way comms takes a lot of time. However, I have just
realised how I can do that without the comma, so I should be able to eliminate
that. The rest, well I'm not sure.
Phil
From: Alan W. Irwin
Sent: 30/12/2015 21:20
To: PLplot development list
Cc: Phil Rosenberg
Subject: Linux wxwidgets inefficiency not solved
On 2015-12-30 17:16-0000 Phil Rosenberg wrote:
> Hi Alan
> Thanks for the test results. I will look to see if I can do a similar test on
> windows, perhaps using Cygwin bash. Then I will see where we stand.
> Just to be sure are you building an optimised or debug build on Linux?
Hi Phil:
I would like to keep this discussion on list in case someone else here
can comment on the IPC question.
Good question above. By historical accident (I have been debugging C and
Fortran issues a lot for the new Fortran binding), my compile flags were
software@raven> printenv |grep FL
CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
CFLAGS=-g
FFLAGS=-g
So assuming -O3 will give a factor of ~2 speed increase, the C++-based
qtwidget and wxwidgets devices should have a two-fold speed advantage
compared to the C-based xwin and xcairo devices.
But the important point is that if you look at the timings for all the
devices, then the sum of user + system timings is normally roughly
equal to the real time required to do the test. But not so for
wxwidgets where the real time is an order of magnitude larger than
that sum, i.e., the problem is not to reduce cpu cycles. Therefore,
the -O3 flag above won't make much difference for the wxwidgets case.
Instead the problem is each example and/or associated wxPLViewer are
simultaneously doing large amounts of waiting while the cpu is
completely idle. My hypothesis to explain those long waits is they
are both waiting too long for communications between them because of
some issue with the way you have set up the IPC method (perhaps
only on Linux, but maybe on Windows also).
My IPC expertise is confined to light skimming of
<https://en.wikipedia.org/wiki/Inter-process_communication> and
<https://en.wikipedia.org/wiki/Shared_memory_(interprocess_communication)>.
I took a look at the latter since it appears you are using the POSIX
shared memory method of IPC on Linux. So I am definitely no expert,
and the above articles only talk about using shared memory for a very
fast way to communicate data between processes. So that part of
efficiency considerations should be fine. But there must be more to
it than that since the processes must communicate between themselves
(presumably with some sort of signal) concerning what data has been
written to that shared memory and how one process wants the other to
service the request implied by the signal that has been sent.
That is, my mental model of the ideal IPC is the -dev wxwidgets code
launches a wxPLViewer application (WA) and the two processes set up
IPC between them. Then the IPC between the two processes is the one
with control goes about its business until it needs the other to
service a request. Then it simply writes needed data for that request
to a shared memory area and sends a specific signal to the other
process to deal with that data, and then that other process receives
that specific signal and deals with that data and continues until it
needs the other process to service a request. Thus, with this ideal
IPC model, the cpu is busy 100 per cent of the time either running
real code (not a wait loop) in either the device or WA. That is, when
either device or WA are waiting while the other is busy, they are
waiting for explicit signals from the other to proceed and are not in
some sort of inefficient sleep x amount of time and wakeup and check
for activity from IPC partner loop.
If you do have such an inefficient wait x amount of time loop in your
code for the Windows case as well, I think you will also find a
similar inefficiency for test_c_wxwidgets compared to test_c_wingcc.
So I will be most interested in your results for that comparison.
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
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
