On 2016-12-24 13:39-0000 p.d.rosenb...@gmail.com wrote: > Hi Alan > It's great that these improvements have borne fruit.
> Regarding the two slower examples, I don't think it is cut and dry that it is > the semaphores are the cause. It may be that for these cases where there are > a large number of elements the ring buffer is filling up so the main > application gets stuck waiting for the viewer to render. To Phil and Pedro: Just to clarify with my unnamed semaphores proof-of-concept project at cmake/test_linux_ipc, I didn't use a ring buffer at all. Instead, it was just a simple shared-memory buffer. The receiving end would sem_wait until the unnamed semaphore set by the sending end said it was time to read. And the sending end would sem_wait to write to that buffer depending on the initial semaphore condition to start and then afterward by how the semaphore was set by the receiving end. And one of the nice advantages of the unnamed semaphores approach is the memory area used by unnamed semaphores for interprocess communication is just part of the shared memory buffer with no file semantics involved. I don't know how big an efficiency improvement that will be, but the important point for me is it does make the code easier to understand. I haven't looked at the current code in this regard but if either end is using a loop with a timed wait to check on conditions for a ring buffer, then that may be an efficiency concern when relatively large amounts of data have to be passed. Anyhow, there are no timed waits at all in the proof-of-concept code, and I think the efficiency of the result (25MBytes of data passed between sender and receiver in 0.3 seconds for a small buffer and even shorter times for larger buffers) speaks for itself. However, instead of me speculating any more about what a great efficiency improvement this _might_ be, this is obviously "show me the code" time. Therefore, after this release is out the door, I plan to implement the proof-of-concept project's ideas in wxwidgets_comms.cpp. And once that is working on a topic branch, I will document the time required on both the -dev wxwidgets end AND the wxPLViewer end for example 8 to complete for both that topic branch and master. And if the proof-of-concept approach turns out to be a net efficiency benefit, push it, but otherwise abandon it. You and Pedro are, of course, welcome to join me in working on this proposed topic branch even if you decide to limit your involvement to acting as a sounding board if I run into trouble with this implementation. 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 __________________________ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
