Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2015-12-28 23:09:10
Attachments:
wxPLViewer.out.gz
|
Hi Phil: For the current tip of master (commit 08d4864) wxPLViewer can no longer be built on Linux, i.e., those following our git version must currently use -DENABLE_wxwidgets=OFF in order to build the master branch. Because this is a default build issue for the master branch that affects a considerable number of people who are attempting to use the master tip version, I hope we will be able to find a fix in short order. The last time I attempted to build the master branch was some time ago, but I am pretty sure this build issue has been introduced by your most recent wxwidgets change, but if there is any uncertainty about which of your commits caused the issue, git bisect is your friend. To help you figure out this build issue, I have attached a compressed version of the output results from make VERBOSE=1 wxPLViewer >& wxPLViewer.out I ran that command after an initial attempt with VERBOSE=1 not set failed. In other words, all prerequisites have already been built, and wxPLViewer.out just gives the VERBOSE=1 part of the build that failed. In case this is a wxWidgets versioning issue, I currently have installed on my Debian Jessie platform the following wx-related packages: irwin@raven> dpkg --list |grep -i wx ii libwxbase3.0-0:amd64 3.0.2-1+b1 amd64 wxBase library (runtime) - non-GUI support classes of wxWidgets toolkit ii libwxbase3.0-dev 3.0.2-1+b1 amd64 wxBase library (development) - non-GUI support classes of wxWidgets toolkit ii libwxgtk3.0-0:amd64 3.0.2-1+b1 amd64 wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime) ii libwxgtk3.0-dev 3.0.2-1+b1 amd64 wxWidgets Cross-platform C++ GUI toolkit (GTK+ development) ii wx-common 3.0.2-1+b1 amd64 wxWidgets Cross-platform C++ GUI toolkit (common support files) ii wx3.0-headers 3.0.2-1+b1 amd64 wxWidgets Cross-platform C++ GUI toolkit (header files) Good luck figuring this out, and let me know if there is any additional information I need to supply. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2015-12-29 17:48:16
|
Hi Alan I think this should be fixed. I don't have easy access to a Linux box right now, but I have tested and the new version builds with gcc on Cygwin. The issue is actually a C++ syntax error and nothing to do with wxWidgets. The short explanation is that this was GCC being stricter than Visual studio regarding syntax. In case you are interested in the long explanation the function wxPLplotwindow<WXWINDOW>::OnMouse is part of a template class which inherits from the template type WXWINDOW. In the case of wxPLViewer this type is a wxFrame. The function GetGlientSize() is a member of wxFrame. Visual Studio realises that the template parameter is instantiated as a wxFrame, sees the inheritance and allows the syntax in your error message to call wxFrame::GetClientSize(), however GCC sees the call to GetClientSize() as part of its pre instatiation checks and cannot find a function definition so gives an error. I am not sure if this is GCC being overly strict or VS being overly permissive or clever. As you can see from the error, passing the permissive flag would allow this to compile with GCC, so who knows. Anyway, the new syntax WXWINDOW::GetClientSize() specifies the scope fully so there should be no worries at all there. It compiles fine on Cygwin GCC so it should be fine on Linux GCC. If you still have any problems let me know. Phil On 28 December 2015 at 23:09, Alan W. Irwin <ir...@be...> wrote: > Hi Phil: > > For the current tip of master (commit 08d4864) wxPLViewer can no > longer be built on Linux, i.e., those following our git version must > currently use -DENABLE_wxwidgets=OFF in order to build the master > branch. Because this is a default build issue for the master branch > that affects a considerable number of people who are attempting to use > the master tip version, I hope we will be able to find a fix in short > order. The last time I attempted to build the master branch was some > time ago, but I am pretty sure this build issue has been introduced by > your most recent wxwidgets change, but if there is any uncertainty > about which of your commits caused the issue, git bisect is your friend. > > To help you figure out this build issue, I have attached a compressed > version of the output results from > > make VERBOSE=1 wxPLViewer >& wxPLViewer.out > > I ran that command after an initial attempt with VERBOSE=1 not set > failed. In other words, all prerequisites have already been built, and > wxPLViewer.out just gives the VERBOSE=1 part of the build that failed. > > In case this is a wxWidgets versioning issue, I currently have installed > on my Debian Jessie platform the following wx-related packages: > > irwin@raven> dpkg --list |grep -i wx > ii libwxbase3.0-0:amd64 3.0.2-1+b1 > amd64 wxBase library (runtime) - non-GUI support classes of wxWidgets > toolkit > ii libwxbase3.0-dev 3.0.2-1+b1 > amd64 wxBase library (development) - non-GUI support classes of > wxWidgets toolkit > ii libwxgtk3.0-0:amd64 3.0.2-1+b1 > amd64 wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime) > ii libwxgtk3.0-dev 3.0.2-1+b1 > amd64 wxWidgets Cross-platform C++ GUI toolkit (GTK+ development) > ii wx-common 3.0.2-1+b1 > amd64 wxWidgets Cross-platform C++ GUI toolkit (common support files) > ii wx3.0-headers 3.0.2-1+b1 > amd64 wxWidgets Cross-platform C++ GUI toolkit (header files) > > Good luck figuring this out, and let me know if there is any > additional information I need to supply. > > 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 > __________________________ |
|
From: Alan W. I. <ir...@be...> - 2015-12-30 10:07:14
|
On 2015-12-29 17:48-0000 Phil Rosenberg wrote: > Hi Alan > I think this should be fixed. I don't have easy access to a Linux box > right now, but I have tested and the new version builds with gcc on > Cygwin. Hi Phil: I confirm the build of the master tip (as of commit 36bd058 Fix compile error for wxPLplotwindow for gcc) now works again on Linux, and the build of the test_c_wxwidgets target also shows no run-time issues. Thank you for quickly addressing this default build issue for master tip. You asked me off list to perform some Linux timing tests of your latest code version. Here are the latest results for the xwin, xcairo, qtwidget, and wxwidgets devices for the interactive test_c_<interactive device> targets which generate interactive results for the 01 04 08 14 16 24 30 C examples (note these targets were temporarily modified for these tests to exclude example 17 since that is much slower than all the rest and particularly slow for xcairo and qtwidget so in any case we always drop it from the list for those devices, see plplot_test/test_c_interactive.sh.in): software@raven> time make -j4 test_c_xwin >& /dev/null real 0m2.896s user 0m1.152s sys 0m0.348s software@raven> time make -j4 test_c_xcairo >& /dev/null real 0m4.514s user 0m3.556s sys 0m0.392s software@raven> time make -j4 test_c_qtwidget >& /dev/null real 0m3.144s user 0m1.688s sys 0m0.372s software@raven> time make -j4 test_c_wxwidgets >& /dev/null real 0m26.273s user 0m1.108s sys 0m0.344s In all cases the tests were done two or more times to build all prerequisites and get everything into memory for the early tests while only the last test result is reported above. So there is still roughly an order of magnitude of inefficiency on Linux for wxwidgets compared to the other devices which to my mind is just barely acceptable. My cpu meter and also the comparison of real and user times for the above results indicates most of that time is spent waiting rather than executing cpu instructions which is why I suspect some badly tuned aspect of the Linux IPC between application and wxPLViewer that generates inordinate amounts of wait time is still the principal cause of these bad efficiency results for wxwidgets on Linux. For the MSVC case can you similarly compare speed results (excluding example 17, see plplot_test/test_c_interactive.sh.in to see where to exclude that example from the list of examples) for the test_c_wingcc target and the test_c_wxwidgets target? If those two times are comparable to each other, then my working hypothesis to explain these results is the Windows IPC is well tuned, but that is not the case for the Linux IPC method that you are currently using. On the other hand, if test_c_wingcc is an order of magnitude faster, perhaps the Windows IPC method is equally badly tuned, and you can find some common factor to speed that up as well as the Linux IPC method. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2015-12-30 21:21:02
|
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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2015-12-30 22:50:54
|
On 2015-12-30 13:20-0800 Alan W. Irwin wrote: > 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. Just found a useful illustrative example via google. Take a look at the "Unamed semaphore example" in <http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf> which uses POSIX semaphores to signal between two processes that are accessing the same POSIX shared memory. Naively, this looks quite efficient to me with no unnecessary simultaneous waits by the two processes since sem_wait just blocks until the other process is finished serving the request. I don't understand drivers/wxwidgets_comms.cpp at all, but I do notice you use sem_open, etc., there. Thus, it appears you are using a similar POSIX semaphore basis of method of control between the two processes that are accessing POSIX shared memory. If so, then I frankly cannot see how both processes would spend so much time simultanously waiting with completely idle cpu unless there is some issue with how you have implemented the use of semaphores. So maybe this would be a good time to carefully review that. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-01 10:36:54
|
Hi Alan Just a quick email while I procrastinate, rather than start tidying from last night's festivities - happy new year by the way :-) You are almost right regarding the ipc. But actually for most things it is a bit simpler than that. The shared memory has a small header area and then a data area which is set up as a circular buffer. The header includes a read pointer and a write pointer. Whenever the driver receives a command it simply adds the new part of the plplot buffer to the data area, then updates the write pointer. The viewer repeatedly checks the read and write pointers and if they are not equal then it reads the new data and updates the read pointer. In this model, the only time the driver should be waiting is if the buffer fills up and the write pointer catches up with the read pointer. Then the driver must wait for the viewer to update. Actually things then got a bit more complicated, because there are other things to deal with such as the cursor position requests etc. But that is the basic model. So in most cases the communication is only one way. Therefore semphores are generally not needed and named semaphores can be very slow - on Linux I think they involve creating a locked file - so I try to avoid them when possible. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 30/12/2015 22:51 To: "PLplot development list" <Plp...@li...> Subject: Re: [Plplot-devel] Linux wxwidgets inefficiency not solved On 2015-12-30 13:20-0800 Alan W. Irwin wrote: > 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. Just found a useful illustrative example via google. Take a look at the "Unamed semaphore example" in <http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf> which uses POSIX semaphores to signal between two processes that are accessing the same POSIX shared memory. Naively, this looks quite efficient to me with no unnecessary simultaneous waits by the two processes since sem_wait just blocks until the other process is finished serving the request. I don't understand drivers/wxwidgets_comms.cpp at all, but I do notice you use sem_open, etc., there. Thus, it appears you are using a similar POSIX semaphore basis of method of control between the two processes that are accessing POSIX shared memory. If so, then I frankly cannot see how both processes would spend so much time simultanously waiting with completely idle cpu unless there is some issue with how you have implemented the use of semaphores. So maybe this would be a good time to carefully review that. 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
|
From: Alan W. I. <ir...@be...> - 2016-01-01 19:59:59
|
On 2016-01-01 10:36-0000 Phil Rosenberg wrote: > Hi Alan > Just a quick email while I procrastinate, rather than start tidying from last night's festivities - happy new year by the way :-) Hi Phil: And Happy New Year to you as well! > You are almost right regarding the ipc. But actually for most things it is a bit simpler than that. The shared memory has a small header area and then a data area which is set up as a circular buffer. The header includes a read pointer and a write pointer. Whenever the driver receives a command it simply adds the new part of the plplot buffer to the data area, then updates the write pointer. The viewer repeatedly checks the read and write pointers and if they are not equal then it reads the new data and updates the read pointer. In this model, the only time the driver should be waiting is if the buffer fills up and the write pointer catches up with the read pointer. Then the driver must wait for the viewer to update. That "repeatedly checks the read and write pointer" sounds like the logic is in a loop that waits N nanosecs and checks the read and write pointer, and that wait could be the source of the issue. > Actually things then got a bit more complicated, because there are other things to deal with such as the cursor position requests etc. But that is the basic model. > So in most cases the communication is only one way. Therefore semphores are generally not needed and named semaphores can be very slow - on Linux I think they involve creating a locked file - so I try to avoid them when possible. >> Just found a useful illustrative example via google. Take a look at >> the "Unamed semaphore example" in >> <http://man7.org/conf/lca2013/IPC_Overview-LCA-2013-printable.pdf> >> which uses POSIX semaphores to signal between two processes that are >> accessing the same POSIX shared memory. Naively, this looks quite >> efficient to me with no unnecessary simultaneous waits by the two >> processes since sem_wait just blocks until the other process is >> finished serving the request. Perhaps the above illustrative example was avoiding named semaphores for that very efficiency reason? Some more googling found <https://sendreceivereply.wordpress.com/2007/04/10/mutex-or-semaphore-for-performance/> which implies efficiency does increase from named semaphore to unamed. Anyhow, the current situation is the wait time (where _neither_ -dev wxwidgets or wxPLViewer are using the cpu) is roughly equal to 10 times the actual cpu time on Linux used by either of those processes. So that is a gross wait inefficiency and not a cpu inefficiency, and I would not be too concerned about any extra cpu cyles that an unnamed semaphore would take. Therefore, I suggest you replace any wait loops with an unnamed semaphore to see if that does solve the wait inefficiency issue. And, of course, I would be happy to test any possible solution to the wait inefficiency that you send me if you are having trouble getting access to Linux yourself. I would also recommend a detailed timing comparisons between -dev wingcc and -dev wxwidgets on MSVC just to make sure you don't have a gross wait inefficiency in that case as well. By the way. I emphasize MSVC for those timing tests because Cygwin has additional timing issues for the interactive PLplot devices which could obfuscate the results. According to what Arjen has told me, the timing results for interactive devices on Cygwin depend very much on whether the underlying interactive library has been built against the native Windows display API (whose name I have forgotten) or X (which in turn is built against the native display API, but which is very slow because of that). So the wingcc device on Cygwin must be built against the native display API and is therefore fast, but the possibility exists that the Cygwin package for the wxwidgets library may build the X version of wxwidgets rather than the native display version which would greatly slow down -dev wxwidgets on Cygwin. There also may be similar concerns on MinGW-w64/MSYS2 depending on how wxwidgets is built on that platform. So I suggest you do timing tests on MSVC first before you start evaluating timing results on those other Unix-like platforms. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-02 16:28:55
|
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 -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 30/12/2015 21:20 To: "PLplot development list" <Plp...@li...> Cc: "Phil Rosenberg" <p.d...@gm...> 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-02 16:34:22
|
Also, i forgot to say, the following command time ./x20c.exe -dev null -np Gives a real time of ~12 s too. -----Original Message----- From: "Phil Rosenberg" <p.d...@gm...> Sent: 02/01/2016 16:28 To: "Alan W. Irwin" <ir...@be...>; "PLplot development list" <Plp...@li...> 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-02 22:53:32
|
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...@gm...> Sent: 02/01/2016 16:34 To: "Phil Rosenberg" <p.d...@gm...>; "Alan W. Irwin" <ir...@be...>; "PLplot development list" <Plp...@li...> 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-01-02 23:25:00
|
On 2016-01-02 22:53-0000 Phil Rosenberg wrote: > 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? It should be enabled by default on Windows. But it may be disabled by some of the tests in cmake/modules/wingcc.cmake. For example, what are the messages you are getting from your cmake invocation concerning "Looking for gdi32 header and library"? Are those found or not found? If the latter, you need to address that issue. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-01-02 23:18:04
|
On 2016-01-02 16:28-0000 Phil Rosenberg wrote: > 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. Example 20 is not the one I measured since that is a special case in many ways. Instead, I ran the test_c_wxwidgets target which runs a list of C examples for -dev wxwidgets -np That list of examples is given in plplot_test/test_c_interactive.sh.in. For my previous tests I locally modified that list here to be "01 04 08 14 16 24 30" for all devices, but you can locally modify it to be any list of examples you want. For example, you could modify it to "01 01 01 01 01 01 .... " to get good timing numbers for a short example such as example 1, see below. Also, your system will have very different speed than mine. So what is important is not comparisons with my numbers, but instead what fraction of time is spent with _both_ example and wxPLViewer application being idle (i.e., both in wait mode) compared to the fraction of time when one of them is using the cpu. This "idle" issue is a substantial problem for the Linux case, and it is currently unknown whether that is a substantial problem for the Windows case until you do the equivalent of the Linux experiments I did below. Note, I have now concluded you cannot reliably estimate the fraction of time in the idle state using the Linux "time" command (or equivalent Windows command-line app) because it only gathers time statistics for the example it is given and obviously cannot account, (say) for separate processes such as wxPLViewer. (So that makes its user and system cpu estimates too small because they do not include the wxPLViewer numbers for those, but the real time is reliable (as also measured by a nearby clock) because wxPLViewer exits before the example exits.) So I redid the above test for the above list of examples, and found the overall time spent on -dev wxwidgets + wxPLViewer is still an order of magnitude larger than for the -dev qtwidget case (29 seconds versus 3.6 seconds). Some of that could be that the Linux wxwidgets library might just be slower that the Linux Qt library. But I think that ratio is unlikely to be such a large factor because ultimately both libraries simply organize calls to the X library which does all the real work on Linux. Furthermore, while I was running those comparisons I looked at a GUI of overall cpu usage, and for -dev qtwidget, the cpu usage was 100 per cent during the time of the test. However, for the combination of -dev wxwidgets + wxPLViewer the total cpu usage varied markedly from example to example. So from this result it appears that some examples have a mix of PLplot commands that don't trigger idle issues on Linux, but many others do. So I looked further at GUI cpu usage results (with the GUI expanded to the whole page so I could look at results with good resolution) for repeated (i.e., 01 01 01, etc.) examples for -dev wxwidgets with the following results for average total cpu usage percentage (these numbers are roughly good to +/- 05 per cent since I am using an average value estimated by eye from a graph and subtracting a ~5 per cent baseline for what the average graph level looks like when the example is not running. I presume this background level I subtract is due to the GUI itself taking some CPU time to display the results as a continously upgraded graph). Also, note I have two cpus and for most cases the plot showed the OS distributed the load 50-50 between them so the numbers below refer to the average individual cpu usage for each cpu. i.e., 100 per cent minus the numbers tabulated below is what I state in the 3rd column which is the fraction of the time the entire system was completely idle (everything in wait state) while running these PLplot examples. example cpu % idle % dominant type of graphics 00 30 % 70 % lines 01 30 % 70 % lines 02 30 % 70 % lines 03 25 % 75 % lines 04 25 % 75 % lines 05 20 % 80 % lines 06 20 % 80 % text 07 15 % 85 % text 08 90 % 10 % fills 15 40 % 60 % lines 16 75 % 25 % fills For most of these examples I also looked at detailed cpu usage graphs for -dev xwin and -dev qtwidget and they were all similar, i.e., above 90 per cent cpu usage with essentially no idle issue at all. So it is pretty clear from the above wxwidgets Linux results there is a severe idle issue for text, still fairly severe for lines, and essentially no issue at all for fills (or else the issue is swamped by some other wxwidgets fill inefficiency since in the case of repeated example 8, -dev xwin, qtwidget, and qtwidgets took a total real time of 6, 5, and 35 seconds. And the corresponding numbers for repeated example 16 were 9, 7, and 26 seconds. Note also that the example 20 you have been looking at also may not have a perceptible "idle" issue because that example is virtually all fills as well. Assuming you can get access to a Windows GUI that plots total cpu usage as a function of time, could you run similar tests to the above for a selection of text, line, and fill examples for -dev wxwidgets and -dev wingcc? Typical ratios of total time taken for wxwidgets versus wingcc for some/all of the examples would be useful as well. > 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. It only takes one sleep call in a loop to make both example and wxwidgets idle a large fraction of the time.... > 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. Example 20, has some overhead due to reading in the Lena file so that is an atypical example I would avoid from that regard. Also, it apparently is fill-dominated so if you are trying to deal with the idle issue, that is not the example to use from my result about that fill-dominated examples don't have perceptible idle issues. > 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. Disabling parts of the wxwidgets device as you have done is a useful idea, but you have to break down the real time numbers above into the part that is cpu and the part that is idle time to make this idea truly effective. So something like the experiments I did above for the Linux case is required in addition to your disabling parts of wxwidgets. If it turns out such experiments show there are no wxwidgets idle issues on Windows, then that narrows down what you have to look at to just the code that is run only for the Linux case. So to summarize this, my recent experiments show that text- and line-dominated examples have a pretty severe idle issue on Linux while fill-dominated examples show no perceptible idle issue. So the highest priority question at the moment is whether or not there is a similar idle issue on Windows. Once we definitely know that, then it makes it much easier for us to decide on the best strategy for tracking down and fixing the idle issue. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-02 23:51:41
|
Hi Alan. Just a quick reply, sorry for top posting, but I'm replying on my phone. The text dominated case idle issues doesn't surprise me. As I said this requires 2 way comms, which is does involve both executables sitting in while sleep loops. I think I can fix this and I will look to do so asap. The line issue surprises me a bit. I will try to look at the cause. Phil -----Original Message----- From: "Alan W. Irwin" <ir...@be...> Sent: 02/01/2016 23:17 To: "Phil Rosenberg" <p.d...@gm...> Cc: "PLplot development list" <Plp...@li...> Subject: RE: Linux wxwidgets idle issue not solved for text- or line-dominatedplots On 2016-01-02 16:28-0000 Phil Rosenberg wrote: > 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. Example 20 is not the one I measured since that is a special case in many ways. Instead, I ran the test_c_wxwidgets target which runs a list of C examples for -dev wxwidgets -np That list of examples is given in plplot_test/test_c_interactive.sh.in. For my previous tests I locally modified that list here to be "01 04 08 14 16 24 30" for all devices, but you can locally modify it to be any list of examples you want. For example, you could modify it to "01 01 01 01 01 01 .... " to get good timing numbers for a short example such as example 1, see below. Also, your system will have very different speed than mine. So what is important is not comparisons with my numbers, but instead what fraction of time is spent with _both_ example and wxPLViewer application being idle (i.e., both in wait mode) compared to the fraction of time when one of them is using the cpu. This "idle" issue is a substantial problem for the Linux case, and it is currently unknown whether that is a substantial problem for the Windows case until you do the equivalent of the Linux experiments I did below. Note, I have now concluded you cannot reliably estimate the fraction of time in the idle state using the Linux "time" command (or equivalent Windows command-line app) because it only gathers time statistics for the example it is given and obviously cannot account, (say) for separate processes such as wxPLViewer. (So that makes its user and system cpu estimates too small because they do not include the wxPLViewer numbers for those, but the real time is reliable (as also measured by a nearby clock) because wxPLViewer exits before the example exits.) So I redid the above test for the above list of examples, and found the overall time spent on -dev wxwidgets + wxPLViewer is still an order of magnitude larger than for the -dev qtwidget case (29 seconds versus 3.6 seconds). Some of that could be that the Linux wxwidgets library might just be slower that the Linux Qt library. But I think that ratio is unlikely to be such a large factor because ultimately both libraries simply organize calls to the X library which does all the real work on Linux. Furthermore, while I was running those comparisons I looked at a GUI of overall cpu usage, and for -dev qtwidget, the cpu usage was 100 per cent during the time of the test. However, for the combination of -dev wxwidgets + wxPLViewer the total cpu usage varied markedly from example to example. So from this result it appears that some examples have a mix of PLplot commands that don't trigger idle issues on Linux, but many others do. So I looked further at GUI cpu usage results (with the GUI expanded to the whole page so I could look at results with good resolution) for repeated (i.e., 01 01 01, etc.) examples for -dev wxwidgets with the following results for average total cpu usage percentage (these numbers are roughly good to +/- 05 per cent since I am using an average value estimated by eye from a graph and subtracting a ~5 per cent baseline for what the average graph level looks like when the example is not running. I presume this background level I subtract is due to the GUI itself taking some CPU time to display the results as a continously upgraded graph). Also, note I have two cpus and for most cases the plot showed the OS distributed the load 50-50 between them so the numbers below refer to the average individual cpu usage for each cpu. i.e., 100 per cent minus the numbers tabulated below is what I state in the 3rd column which is the fraction of the time the entire system was completely idle (everything in wait state) while running these PLplot examples. example cpu % idle % dominant type of graphics 00 30 % 70 % lines 01 30 % 70 % lines 02 30 % 70 % lines 03 25 % 75 % lines 04 25 % 75 % lines 05 20 % 80 % lines 06 20 % 80 % text 07 15 % 85 % text 08 90 % 10 % fills 15 40 % 60 % lines 16 75 % 25 % fills For most of these examples I also looked at detailed cpu usage graphs for -dev xwin and -dev qtwidget and they were all similar, i.e., above 90 per cent cpu usage with essentially no idle issue at all. So it is pretty clear from the above wxwidgets Linux results there is a severe idle issue for text, still fairly severe for lines, and essentially no issue at all for fills (or else the issue is swamped by some other wxwidgets fill inefficiency since in the case of repeated example 8, -dev xwin, qtwidget, and qtwidgets took a total real time of 6, 5, and 35 seconds. And the corresponding numbers for repeated example 16 were 9, 7, and 26 seconds. Note also that the example 20 you have been looking at also may not have a perceptible "idle" issue because that example is virtually all fills as well. Assuming you can get access to a Windows GUI that plots total cpu usage as a function of time, could you run similar tests to the above for a selection of text, line, and fill examples for -dev wxwidgets and -dev wingcc? Typical ratios of total time taken for wxwidgets versus wingcc for some/all of the examples would be useful as well. > 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. It only takes one sleep call in a loop to make both example and wxwidgets idle a large fraction of the time.... > 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. Example 20, has some overhead due to reading in the Lena file so that is an atypical example I would avoid from that regard. Also, it apparently is fill-dominated so if you are trying to deal with the idle issue, that is not the example to use from my result about that fill-dominated examples don't have perceptible idle issues. > 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. Disabling parts of the wxwidgets device as you have done is a useful idea, but you have to break down the real time numbers above into the part that is cpu and the part that is idle time to make this idea truly effective. So something like the experiments I did above for the Linux case is required in addition to your disabling parts of wxwidgets. If it turns out such experiments show there are no wxwidgets idle issues on Windows, then that narrows down what you have to look at to just the code that is run only for the Linux case. So to summarize this, my recent experiments show that text- and line-dominated examples have a pretty severe idle issue on Linux while fill-dominated examples show no perceptible idle issue. So the highest priority question at the moment is whether or not there is a similar idle issue on Windows. Once we definitely know that, then it makes it much easier for us to decide on the best strategy for tracking down and fixing the idle issue. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-01-03 01:52:21
|
On 2016-01-02 23:51-0000 Phil Rosenberg wrote: > The text dominated case idle issues doesn't surprise me. As I said this requires 2 way comms, which is does involve both executables sitting in while sleep loops. I think I can fix this and I will look to do so asap. The line issue surprises me a bit. I will try to look at the cause. To help you narrow down what the Linux issues are I just tested a pure ascii test case (the last 6 pages of example 23) and a pure line case (example 00 with the pllab call commented out, and the last argument to plenv set to -2 so absolutely no text is plotted at all by that example). and here are those results: Number cpu% idle% type of example modified 23 25% 75% pure ascii text with no graphics at all modified 00 20%* 80%* pure line graphics with no text So whatever the idle problem is seems to be roughly the same for pure text or pure line graphics. Furthermore, I put an asterisk by that second result because the first time I ran test_c_wxwidgets with 30 repetitions of the modified 00 example in plplot_test/test_c_interactive.sh.in, the cpu usage was effectively zero (at the background level) for each of the first ~25 repetitions or so. Essentially for each of these repetitions there would be a blip of cpu activity at either the start or end of the repetition but nothing else discernible on the graph for the relatively long times it took to finish each repetition. Then for the last 5 repetitions the idle issue went from completely horrible to merely bad (i.e., the idle% dropped from ~99 % to the 80% I state above). And then it stayed in that "bad" state for the next 30 repetitions I tried. Anyhow, because that modified example 00 is so simple with no text at all, that is the example I suggest you should investigate first for the cause of this clear idle issue on Linux that varies between completely horrible to just merely bad. :-) And if you cannot replicate that modified 00 idle issue on Windows, then it is likely time to attempt to verify it on the Ubuntu Linux box you have access to. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-04 12:46:54
|
Hi Alan I have just committed a change that deals with getting text size without two-way communication between the viewer and the driver. The text size is now performed entirely within the driver. This significantly improves the qualitative responsiveness of running the examples. To compare, on my Windows system I created a shell script that just ran examples 01, 04, 08, 14, 16, 24 and 30 using -dev wxWidgets -np and another script that was identical but used -dev null Running these under Cygwin bash using time ./nameofscript.sh gave the following pre commit with -dev wxwidgets real 0m17.248s user 0m0.060s sys 0m0.262s post commit with -dev wxWidgets real 0m7.709s user 0m0.076s sys 0m0.260s with -dev null real 0m4.060s user 0m0.061s sys 0m0.292s So this has given more than a factor of two improvement for those examples and results in a time which is approximately a factor of two longer than doing no rendering at all. I would personally be quite happy with that given the overheads involved in executing the extra process and setting up the shared memory. I still haven't got easy access to my home Linux system as for some reason it will no longer connect to the internet (but will connect to the lan e.g. to load my router's setup page). I think I only have wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a sensible comparison. If you want to check things out on your Linux box then please let me know the results. Phil |
|
From: Alan W. I. <ir...@be...> - 2016-01-04 20:13:23
|
On 2016-01-04 12:46-0000 Phil Rosenberg wrote:
> Hi Alan
> I have just committed a change that deals with getting text size
> without two-way communication between the viewer and the driver. The
> text size is now performed entirely within the driver.
>
> This significantly improves the qualitative responsiveness of running
> the examples. To compare, on my Windows system I created a shell
> script that just ran examples 01, 04, 08, 14, 16, 24 and 30 using
> -dev wxWidgets -np and another script that was identical but used -dev
> null Running these under Cygwin bash using time ./nameofscript.sh gave
> the following
>
> pre commit with -dev wxwidgets
> real 0m17.248s
> user 0m0.060s
> sys 0m0.262s
>
> post commit with -dev wxWidgets
> real 0m7.709s
> user 0m0.076s
> sys 0m0.260s
>
> with -dev null
> real 0m4.060s
> user 0m0.061s
> sys 0m0.292s
>
> So this has given more than a factor of two improvement for those
> examples and results in a time which is approximately a factor of two
> longer than doing no rendering at all. I would personally be quite
> happy with that given the overheads involved in executing the extra
> process and setting up the shared memory.
>
> I still haven't got easy access to my home Linux system as for some
> reason it will no longer connect to the internet (but will connect to
> the lan e.g. to load my router's setup page). I think I only have
> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a
> sensible comparison. If you want to check things out on your Linux box
> then please let me know the results.
The above timing results seem promising indeed, but the changed
version for current master tip (commit 10973c88c) segfaults here at
run time. Here are the relevant valgrind results for the compile flags
software@raven> printenv |grep FL
CXXFLAGS=-g
CFLAGS=-g
FFLAGS=-g
to help improve line number feedback from valgrind
software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets
==2403== Memcheck, a memory error detector
==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2403== Command: examples/c/x00c -dev wxwidgets
==2403==
(process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed
==2403== Invalid read of size 8
==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403== by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403== by 0x4E571E9: plP_init (plcore.c:144)
==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403== by 0x400A01: main (x00c.c:44)
==2403== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==2403==
==2403==
==2403== Process terminating with default action of signal 11 (SIGSEGV)
==2403== Access not within mapped region at address 0x18
==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403== by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403== by 0x4E571E9: plP_init (plcore.c:144)
==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403== by 0x400A01: main (x00c.c:44)
==2403== If you believe this happened as a result of a stack
==2403== overflow in your program's main thread (unlikely but
==2403== possible), you can try to increase the size of the
==2403== main thread stack using the --main-stacksize= flag.
==2403== The main thread stack size used in this run was 8388608.
==2403==
==2403== HEAP SUMMARY:
==2403== in use at exit: 417,068 bytes in 3,235 blocks
==2403== total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes allocated
==2403==
==2403== LEAK SUMMARY:
==2403== definitely lost: 0 bytes in 0 blocks
==2403== indirectly lost: 0 bytes in 0 blocks
==2403== possibly lost: 41,636 bytes in 541 blocks
==2403== still reachable: 363,912 bytes in 2,619 blocks
==2403== suppressed: 0 bytes in 0 blocks
==2403== Rerun with --leak-check=full to see details of leaked memory
==2403==
==2403== For counts of detected and suppressed errors, rerun with: -v
==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
For what it is worth, this was all done with the C 00 example modified
as follows to remove all text from the plot (because I decided to
check your new commit with this non-text case first).
index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
plinit();
// Create a labelled box to hold the plot.
- plenv( xmin, xmax, ymin, ymax, 0, 0 );
- pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+ plenv( xmin, xmax, ymin, ymax, 0, -2 );
+ //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
// Plot the data that was prepared above.
plline( NSIZE, x, y );
Let me know if there is any other experiment (i.e., a specific gdb run)
that you need me to do to help you find and fix this issue.
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
__________________________
|
|
From: Phil R. <p.d...@gm...> - 2016-01-05 13:17:56
|
Thanks Alan
Do you want me to revert the commit?
This is obviously a wxWidgets thing. In order to determine the size of the text I need a device context to do the calculation with. On windows there seems to be no problem creating a memory device context within a console application. But on Linux gdk obviously doesn't like it.
I'll ask on the wxWidgets board if there is a workaround.
Phil
-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: 04/01/2016 20:13
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: Linux wxwidgets idle issue not solved for text- or line-dominatedplots
On 2016-01-04 12:46-0000 Phil Rosenberg wrote:
> Hi Alan
> I have just committed a change that deals with getting text size
> without two-way communication between the viewer and the driver. The
> text size is now performed entirely within the driver.
>
> This significantly improves the qualitative responsiveness of running
> the examples. To compare, on my Windows system I created a shell
> script that just ran examples 01, 04, 08, 14, 16, 24 and 30 using
> -dev wxWidgets -np and another script that was identical but used -dev
> null Running these under Cygwin bash using time ./nameofscript.sh gave
> the following
>
> pre commit with -dev wxwidgets
> real 0m17.248s
> user 0m0.060s
> sys 0m0.262s
>
> post commit with -dev wxWidgets
> real 0m7.709s
> user 0m0.076s
> sys 0m0.260s
>
> with -dev null
> real 0m4.060s
> user 0m0.061s
> sys 0m0.292s
>
> So this has given more than a factor of two improvement for those
> examples and results in a time which is approximately a factor of two
> longer than doing no rendering at all. I would personally be quite
> happy with that given the overheads involved in executing the extra
> process and setting up the shared memory.
>
> I still haven't got easy access to my home Linux system as for some
> reason it will no longer connect to the internet (but will connect to
> the lan e.g. to load my router's setup page). I think I only have
> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a
> sensible comparison. If you want to check things out on your Linux box
> then please let me know the results.
The above timing results seem promising indeed, but the changed
version for current master tip (commit 10973c88c) segfaults here at
run time. Here are the relevant valgrind results for the compile flags
software@raven> printenv |grep FL
CXXFLAGS=-g
CFLAGS=-g
FFLAGS=-g
to help improve line number feedback from valgrind
software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets
==2403== Memcheck, a memory error detector
==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2403== Command: examples/c/x00c -dev wxwidgets
==2403==
(process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed
(process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed
==2403== Invalid read of size 8
==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403== by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403== by 0x4E571E9: plP_init (plcore.c:144)
==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403== by 0x400A01: main (x00c.c:44)
==2403== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==2403==
==2403==
==2403== Process terminating with default action of signal 11 (SIGSEGV)
==2403== Access not within mapped region at address 0x18
==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403== by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403== by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403== by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403== by 0x4E571E9: plP_init (plcore.c:144)
==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403== by 0x400A01: main (x00c.c:44)
==2403== If you believe this happened as a result of a stack
==2403== overflow in your program's main thread (unlikely but
==2403== possible), you can try to increase the size of the
==2403== main thread stack using the --main-stacksize= flag.
==2403== The main thread stack size used in this run was 8388608.
==2403==
==2403== HEAP SUMMARY:
==2403== in use at exit: 417,068 bytes in 3,235 blocks
==2403== total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes allocated
==2403==
==2403== LEAK SUMMARY:
==2403== definitely lost: 0 bytes in 0 blocks
==2403== indirectly lost: 0 bytes in 0 blocks
==2403== possibly lost: 41,636 bytes in 541 blocks
==2403== still reachable: 363,912 bytes in 2,619 blocks
==2403== suppressed: 0 bytes in 0 blocks
==2403== Rerun with --leak-check=full to see details of leaked memory
==2403==
==2403== For counts of detected and suppressed errors, rerun with: -v
==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
For what it is worth, this was all done with the C 00 example modified
as follows to remove all text from the plot (because I decided to
check your new commit with this non-text case first).
index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
plinit();
// Create a labelled box to hold the plot.
- plenv( xmin, xmax, ymin, ymax, 0, 0 );
- pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+ plenv( xmin, xmax, ymin, ymax, 0, -2 );
+ //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
// Plot the data that was prepared above.
plline( NSIZE, x, y );
Let me know if there is any other experiment (i.e., a specific gdb run)
that you need me to do to help you find and fix this issue.
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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2016-01-05 19:06:41
|
On 2016-01-05 13:17-0000 Phil Rosenberg wrote: > This is obviously a wxWidgets thing. In order to determine the size of the text I need a device context to do the calculation with. On windows there seems to be no problem creating a memory device context within a console application. But on Linux gdk obviously doesn't like it. > I'll ask on the wxWidgets board if there is a workaround. Hi Phil: The wxWidgets library does purport to be cross-platform so I would be surprised if there was not some easy way of doing what you want to do that works on both Windows and Linux. [out of order] > Do you want me to revert the commit? Not urgently, but probably by this weekend if no solution can be found. The effect of the commit on Linux is interactive tests will not be able to finish unless wxwidgets is specifically disabled. So this does have some impact on those attempting to use master tip (although it is not nearly as severe as a build issue). For build issues that cannot be instantly resolved, I would revert the offending commit almost immediately. For run-time issues like this, we can be a little more relaxed about the urgency of reverting the change. By the way, the "git diff" command (to create a patch) and "git am --reverse" command to remove the change in that patch should help you make that public commit that removes your change. That method allows you to preserve the patch (or even commit it on a private topic branch with the aid of "git am") for future reference in case a method is found in the long term to make a slightly modified version of this approach work on Linux. 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 __________________________ |
|
From: Phil R. <p.d...@gm...> - 2016-01-05 14:13:56
|
Hi Alan After posting on the wx forum, I realised I had the full wx sourcecode (including wxGTK) on my system from their Git repo. A quick scan seems to have revealed the issue. Could you try the following test for me? In wxWidgets_dev.cpp on line 443, could you change wxBITMAP_SCREEN_DEPTH to 24. I think the problem is that when creating the bitmap on Linux, wxWidgets tries to get the screen depth from the top level window, which doesn't exist in this case, whereas on Windows it creates a screen dc and uses this to get the depth. If the fix above works I'll report it as a wxWidgets bug. If this fix works then please feel free to commit it so we get things working again as soon as possible. Phil On 5 January 2016 at 13:17, Phil Rosenberg <p.d...@gm...> wrote: > Thanks Alan > Do you want me to revert the commit? > > This is obviously a wxWidgets thing. In order to determine the size of the > text I need a device context to do the calculation with. On windows there > seems to be no problem creating a memory device context within a console > application. But on Linux gdk obviously doesn't like it. > > I'll ask on the wxWidgets board if there is a workaround. > > Phil > ________________________________ > From: Alan W. Irwin > Sent: 04/01/2016 20:13 > To: Phil Rosenberg > Cc: PLplot development list > Subject: Re: Linux wxwidgets idle issue not solved for text- or > line-dominatedplots > > On 2016-01-04 12:46-0000 Phil Rosenberg wrote: > >> Hi Alan >> I have just committed a change that deals with getting text size >> without two-way communication between the viewer and the driver. The >> text size is now performed entirely within the driver. >> >> This significantly improves the qualitative responsiveness of running >> the examples. To compare, on my Windows system I created a shell >> script that just ran examples 01, 04, 08, 14, 16, 24 and 30 using >> -dev wxWidgets -np and another script that was identical but used -dev >> null Running these under Cygwin bash using time ./nameofscript.sh gave >> the following >> >> pre commit with -dev wxwidgets >> real 0m17.248s >> user 0m0.060s >> sys 0m0.262s >> >> post commit with -dev wxWidgets >> real 0m7.709s >> user 0m0.076s >> sys 0m0.260s >> >> with -dev null >> real 0m4.060s >> user 0m0.061s >> sys 0m0.292s >> >> So this has given more than a factor of two improvement for those >> examples and results in a time which is approximately a factor of two >> longer than doing no rendering at all. I would personally be quite >> happy with that given the overheads involved in executing the extra >> process and setting up the shared memory. >> >> I still haven't got easy access to my home Linux system as for some >> reason it will no longer connect to the internet (but will connect to >> the lan e.g. to load my router's setup page). I think I only have >> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a >> sensible comparison. If you want to check things out on your Linux box >> then please let me know the results. > > The above timing results seem promising indeed, but the changed > version for current master tip (commit 10973c88c) segfaults here at > run time. Here are the relevant valgrind results for the compile flags > > software@raven> printenv |grep FL > CXXFLAGS=-g > CFLAGS=-g > FFLAGS=-g > > to help improve line number feedback from valgrind > > software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets > ==2403== Memcheck, a memory error detector > ==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==2403== Command: examples/c/x00c -dev wxwidgets > ==2403== > > (process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance > > (process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion > 'G_TYPE_CHECK_INSTANCE (instance)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: > assertion 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion > 'GDK_IS_COLORMAP (colormap)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: > assertion 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion > 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion > 'GDK_IS_SCREEN (screen)' failed > > (process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion > 'GDK_IS_WINDOW (parent)' failed > ==2403== Invalid read of size 8 > ==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in > /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25) > ==2403== by 0x8C6E1DD: ??? (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x9CB8473: ??? (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD2086: g_signal_emit_valist (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD29DE: g_signal_emit (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x8C62063: gtk_widget_realize (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x7C5C0D9: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C622A8: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) > (wxwidgets_dev.cpp:443) > ==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174) > ==2403== by 0x4E571E9: plP_init (plcore.c:144) > ==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345) > ==2403== by 0x400A01: main (x00c.c:44) > ==2403== Address 0x18 is not stack'd, malloc'd or (recently) free'd > ==2403== > ==2403== > ==2403== Process terminating with default action of signal 11 (SIGSEGV) > ==2403== Access not within mapped region at address 0x18 > ==2403== at 0x90D0859: gdk_window_enable_synchronized_configure (in > /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25) > ==2403== by 0x8C6E1DD: ??? (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x9CB8473: ??? (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD2086: g_signal_emit_valist (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x9CD29DE: g_signal_emit (in > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) > ==2403== by 0x8C62063: gtk_widget_realize (in > /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) > ==2403== by 0x7C5C0D9: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C622A8: ??? (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7C6266D: wxBitmap::Create(int, int, int) (in > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) > ==2403== by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) > (wxwidgets_dev.cpp:443) > ==2403== by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174) > ==2403== by 0x4E571E9: plP_init (plcore.c:144) > ==2403== by 0x4E5C6C7: c_plinit (plcore.c:2345) > ==2403== by 0x400A01: main (x00c.c:44) > ==2403== If you believe this happened as a result of a stack > ==2403== overflow in your program's main thread (unlikely but > ==2403== possible), you can try to increase the size of the > ==2403== main thread stack using the --main-stacksize= flag. > ==2403== The main thread stack size used in this run was 8388608. > ==2403== > ==2403== HEAP SUMMARY: > ==2403== in use at exit: 417,068 bytes in 3,235 blocks > ==2403== total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes > allocated > ==2403== > ==2403== LEAK SUMMARY: > ==2403== definitely lost: 0 bytes in 0 blocks > ==2403== indirectly lost: 0 bytes in 0 blocks > ==2403== possibly lost: 41,636 bytes in 541 blocks > ==2403== still reachable: 363,912 bytes in 2,619 blocks > ==2403== suppressed: 0 bytes in 0 blocks > ==2403== Rerun with --leak-check=full to see details of leaked memory > ==2403== > ==2403== For counts of detected and suppressed errors, rerun with: -v > ==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > Segmentation fault > > For what it is worth, this was all done with the C 00 example modified > as follows to remove all text from the plot (because I decided to > check your new commit with this non-text case first). > > index aa4683c..1aaa4f2 100644 > --- a/examples/c/x00c.c > +++ b/examples/c/x00c.c > @@ -44,8 +44,8 @@ main( int argc, const char *argv[] ) > plinit(); > > // Create a labelled box to hold the plot. > - plenv( xmin, xmax, ymin, ymax, 0, 0 ); > - pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" ); > + plenv( xmin, xmax, ymin, ymax, 0, -2 ); > + //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" ); > > // Plot the data that was prepared above. > plline( NSIZE, x, y ); > > > Let me know if there is any other experiment (i.e., a specific gdb run) > that you need me to do to help you find and fix this issue. > > 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 > __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-01-05 19:44:31
|
On 2016-01-05 14:13-0000 Phil Rosenberg wrote: > Hi Alan > After posting on the wx forum, I realised I had the full wx sourcecode > (including wxGTK) on my system from their Git repo. A quick scan seems > to have revealed the issue. Could you try the following test for me? > In wxWidgets_dev.cpp on line 443, could you change wxBITMAP_SCREEN_DEPTH to 24. > > I think the problem is that when creating the bitmap on Linux, > wxWidgets tries to get the screen depth from the top level window, > which doesn't exist in this case, whereas on Windows it creates a > screen dc and uses this to get the depth. If the fix above works I'll > report it as a wxWidgets bug. > Sorry, but that temporary fix did not work. Here is the valgrind result (in case you spot anything different from this change). software@raven> valgrind examples/c/x00c -dev wxwidgets ==13810== Memcheck, a memory error detector ==13810== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==13810== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==13810== Command: examples/c/x00c -dev wxwidgets ==13810== (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width_mm: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height_mm: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width_mm: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height_mm: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): GLib-GObject-WARNING **: invalid (NULL) pointer instance (process:13810): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (process:13810): GLib-GObject-WARNING **: invalid (NULL) pointer instance (process:13810): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed (process:13810): Gdk-CRITICAL **: IA__gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed ==13810== Invalid read of size 8 ==13810== at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25) ==13810== by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) ==13810== by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) ==13810== by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) ==13810== by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) ==13810== by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) ==13810== by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C54469: wxNativeFontInfo::GetFamily() const (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C85650: wxFont::wxFont(wxNativeFontInfo const&) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C93903: wxSystemSettingsNative::GetFont(wxSystemFont) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7DEACE9: wxStockGDI::GetFont(wxStockGDI::Item) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C757E2: wxGTKDCImpl::wxGTKDCImpl(wxDC*) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==13810== ==13810== ==13810== Process terminating with default action of signal 11 (SIGSEGV) ==13810== Access not within mapped region at address 0x18 ==13810== at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25) ==13810== by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) ==13810== by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) ==13810== by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) ==13810== by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1) ==13810== by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25) ==13810== by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C54469: wxNativeFontInfo::GetFamily() const (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C85650: wxFont::wxFont(wxNativeFontInfo const&) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C93903: wxSystemSettingsNative::GetFont(wxSystemFont) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7DEACE9: wxStockGDI::GetFont(wxStockGDI::Item) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== by 0x7C757E2: wxGTKDCImpl::wxGTKDCImpl(wxDC*) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0) ==13810== If you believe this happened as a result of a stack ==13810== overflow in your program's main thread (unlikely but ==13810== possible), you can try to increase the size of the ==13810== main thread stack using the --main-stacksize= flag. ==13810== The main thread stack size used in this run was 8388608. ==13810== ==13810== HEAP SUMMARY: ==13810== in use at exit: 430,557 bytes in 3,390 blocks ==13810== total heap usage: 5,092 allocs, 1,702 frees, 1,206,877 bytes allocated ==13810== ==13810== LEAK SUMMARY: ==13810== definitely lost: 0 bytes in 0 blocks ==13810== indirectly lost: 0 bytes in 0 blocks ==13810== possibly lost: 42,408 bytes in 554 blocks ==13810== still reachable: 373,069 bytes in 2,737 blocks ==13810== suppressed: 0 bytes in 0 blocks ==13810== Rerun with --leak-check=full to see details of leaked memory ==13810== ==13810== For counts of detected and suppressed errors, rerun with: -v ==13810== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault One issue with your temporary fix on my system could be if the X server does not actually have a color depth of 24. But I double-checked that by running the xwininfo command which gave "Depth: 24" both when running on a thin client (X-terminal) with the local X server interacting with desktop software running on a remote fast computer OR when running the local X server on the same computer where the desktop software is running. Note the above segfault result was for the direct use of desktop software, but I also got a segfault for the remote case as well. I am perfectly happy to help out as much as possible by running tests like this for you, but it is an inherently clumsy and slow process (especially with the time zone difference between us which virtually guarantees a day's delay between question and answer). And there are likely many more Linux tests you will want to run in the immediate future as you gradually figure out the Linux idle issue(s). And some of the Linux issues I report to you may be because of some inadequacy of my Debian jessie system. So I suggest you would probably be much better served by taking the time now to fix both your home Linux networking as well as getting wxwidgets-3.0 built on the Linux box you have access to at work so you have two Linux boxes where you can get essentially instant feedback on your changes. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-01-06 21:44:19
|
On 2016-01-06 16:35-0000 Phil Rosenberg wrote:
> You should now have a working version on Linux. It certainly seems to
> work on my CentOS machine.
Yep. Works fine here with no build or run-time problems other than the
idle issue(s) which I document below for this (commit 4677df1) version
of wxwidgets.
Here are the additional local changes I made to make example 00 pure
line graphics with no text, example 23 pure ascii text with no
graphics, and a given example (in this case example 00, but I
modified it to example 23 for the example 23 tests) is repeated 19
times (10 times for the example 23 case) when building the
test_c_<interactive device> target.
==================
diff --git a/examples/c/x00c.c b/examples/c/x00c.c
index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
plinit();
// Create a labelled box to hold the plot.
- plenv( xmin, xmax, ymin, ymax, 0, 0 );
- pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+ plenv( xmin, xmax, ymin, ymax, 0, -2 );
+ //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
// Plot the data that was prepared above.
plline( NSIZE, x, y );
diff --git a/examples/c/x23c.c b/examples/c/x23c.c
index 5dddf3b..3b67a60 100644
--- a/examples/c/x23c.c
+++ b/examples/c/x23c.c
@@ -229,6 +229,7 @@ main( int argc, const char *argv[] )
plinit();
+#if 0
for ( page = 0; page < 11; page++ )
{
pladv( 0 );
@@ -292,6 +293,7 @@ main( int argc, const char *argv[] )
printf( "For example 23 prior to page 12 the FCI is 0x%x\n", fci_old );
printf( "For example 23 prior to page 12 the font family, style and weight are %s %s %s\n", family[ifamily], style[istyle], weight[iweight] );
+#endif
for ( page = 11; page < 16; page++ )
{
PLFLT dy = 0.030;
diff --git a/plplot_test/test_c_interactive.sh.in b/plplot_test/test_c_interactive.sh.in
index 6e6ceea..3736a0a 100755
--- a/plplot_test/test_c_interactive.sh.in
+++ b/plplot_test/test_c_interactive.sh.in
@@ -27,12 +27,12 @@
lang="c"
export index lang
-if [ "$device" = "xcairo" -o "$device" = "qtwidget" ] ; then
+if [ "$device" = "xcairo1" -o "$device" = "qtwidget1" ] ; then
# Temporarily drop example 17 for xcairo and qtwidget because those drivers are
# so horribly slow for such interactive plots.
INDEX="01 04 08 14 16 24 30"
else
- INDEX="01 04 08 14 16 17 24 30"
+ INDEX="00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "
fi
for index in $INDEX; do
if [ "$verbose_test" ] ; then
==================
Please look at the attached screenshots of results from my system
monitor. The only relevant part to look at is the cpu history, and
all these results were obtained by running X on the same computer
where the desktop software was running.
I. Pure line graphics results from 19 repetitions of modified example 00.
Ia. Comments on screenshot_others00.png
The three major peaks here correspond to building the three separate
targets test_c_xwin, test_c_xcairo, and test_c_qtwidget. Each of
these targets completes the 19 runs of modified example 00 in
respectively 2.5, 2.9, and 4.0 seconds. These numbers are confirmed
by the relative width of each of the major 3 peaks.
Ib. Comments on screenshot_wxwidgets00.png
This is my primary evidence of the idle problem(s) for a pure line
graphics case (modified 00 example).
This cpu history corresponds to several minutes of building the
test_c_wxwidgets target for the second time (so that all prerequisites
are built, and everything relevant is in memory).
The initial large peak corresponds to the cpu time that cmake requires
to run through all the dependencies of the target to insure they have
all been built. That peak is then followed by 11 more peaks as -dev
wxwidgets runs through 11 of the 19 example 00 repetitions before I
had to take the screenshot so as not to miss the first peak. You can
see for each of these examples both my cpus are engaged, and a given
repetition consists of mostly idle time of wildly different durations
with one modest peak of cpu(s) activity per repetition. It turns out
these modest peaks correspond to exactly when the wxPLViewer GUI is
visible on the screen (although it just displays a black screen during
that time because of the -np issue with wxPLViewer). From the random
duration of the idle times for each repetition the figure for the
total time that all 19 repetitions take is quite variable. However,
the one time I had the patience to measure the time required for the
full 19 the result was 467 (!) seconds which is more than two orders
of magnitude larger than corresponding example 00 results for three
other interactive devices that I give above.
II. Pure ascii text results from 10 repetitions of modified example 23.
IIa. Comments on screenshot_others23.png
The three major peaks here correspond to building the three separate
targets test_c_xwin, test_c_xcairo, and test_c_qtwidget. Each of
these targets completes 10 runs of modified example 23 in
respectively 3.3, 4.3, and 5.4 seconds. These numbers are confirmed
by the relative width of each of the major 3 peaks.
Comments on screenshot_wxwidgets23.png
This is my primary evidence of the idle problem(s) for a pure ascii text
case (modified 23 example).
This cpu history corresponds to several minutes of building the
test_c_wxwidgets target for the second time (so that all prerequisites
are built, and everything relevant is in memory).
The initial large peak (all of which is clipped off on the left except
for the trailing part) corresponds to the cpu time that cmake requires
to run through all the dependencies of the target to insure they have
all been built. That peak is then followed by 8 more peaks as -dev
wxwidgets runs through 8 of the 10 example 23 repetitions before I had
to take the screenshot so as not to miss all of the first peak. The
remarks I made concerning variability of idle time, coincidence of the
peaks with GUI display for screenshot_wxwidgets00.png all apply for
this case as well. The one time I measured the time required for the
full 10 repetitions the result was 113 seconds or more than an order
of magnitude more than the corresponding example 23 results for three
other interactive devices that I give above, but almost an order of
magnitude less than the modified example 00 case for wxwidgets.
In sum, it appears that we may have at least two separate idle issues
left on Linux for -dev wxwidgets since the time required to get
through the repeated modified x00 example is roughly equivalent to the
corresponding time taken for the repeated x23 example for the other
interactive devices, but almost an order of magnitude slower for
repeated x00 versus repeated x23 for the wxwidgets device.
So the biq question is can you replicate these results (at least the
one or two order of magnitude differences in relative total times
involved to run these various targets) on your own two Linux systems
or are they idiosyncratic to my Debian jessie platform?
Assuming you can replicate, then good luck on the bug hunt to find
the source of these Linux idle issues.
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
__________________________
|
|
From: Alan W. I. <ir...@be...> - 2016-01-06 21:49:07
|
Oops. Here are the attachments which I meant to attach to the last post. __________________________ 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X