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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
