On 2015-01-28 01:06-0000 Phil Rosenberg wrote: > Hi Alan > I know we are way off topic here, but how come you are reallocating so > often? Perhaps you might be interested in memory pools, or object > oriented style C or even C++ for saving you some of those allocations.
Thanks, Phil, for that good question. I just did a quick review of the use of the 2d allocator functions in ephcom, and it turns out the efficiency of those functions is only a concern for one function in the Fortran binding of the libephcomc C library. For that one function, interpolated results from libephcomc are returned in an nlist x 6 2D array (where nlist is the number of objects in the list of objects that is interpolated from the ephemeris and 6 is the number of coordinates, i.e., 3 positions and 3 velocities). nlist can range anywhere from 1 to an absolute maximum limit of 400, and some temporary space is required to hold those C results so they can be transformed into the equivalent Fortran 2D array. That space could be created statically with some maximum size like 400x6, but that creates a thread safety issue which is an important consideration in Fortran because of all the parallelization that is routinely done in that language. So instead, for _every_ interpolation, I naively used the 2d allocator for doubles to create the required temporary memory space and free it again in a thread-safe (but obviously inefficient) way. However, your good question has stimulated me to consider thread-safe but efficient alternatives to this naive approach, and it turns out there is an obvious one (2D allocate only once with 400x6) which should be straightforward to implement. Once that is done, I am expecting to see some noticeable efficiency improvements from that change for the Fortran application case I mentioned before with 22 million ephemeris interpolation calls. Thus, similar to the decision that was reached for the PLplot case, I am going to drop the idea of changing the internal implemention of the 2d allocator to make it more efficient since there is little point any more. I think we have reached the end of this thread. Thanks very much for this good discussion of this interesting 2d allocator topic (which a google search shows is also interesting to a lot of other C developers). Thanks also for everyone's patience with the ephcom parts of the discussion. 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
