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.
Phil On 27 January 2015 at 22:20, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-01-27 21:39-0000 Andrew Ross wrote: > >> The sane way round this [potential misalignment issue] is make two >> allocations, one for the array of >> pointers and one for all the data. This is still a lot more efficient >> than the current multiple allocation approach, but still always >> guarantees correct alignment etc. > > Hi Andrew: > > I also saw your two mallocs idea suggested somewhere in my recent > reading, and I have not seen Jim's single malloc alternative (or my > aligned variant of it) mentioned anywhere other than here. > Nevertheless, the aligned variant of Jim's idea is guaranteed to work > and does have the small advantage that the destructor (in Phil's > terminology) is simply a call to free that requires no special routine > to free the two memory areas. Note the ephcom API is quite small > (currently only 14 functions with 3 of those strongly deprecated). > Therefore reducing that API to only 11 functions (by replacing two variants > of the 2d constructor by one, and by dropping the two special > destructor functions) seems like a simplification that will make the > API slightly easier to learn for someone who is just starting with > ephcom. > > You will be amused to learn that I first "discovered" alignment issues > in 1970 or so in conjunction with Fortran common blocks. The solution > in that case was always to put the largest objects first in the common > block. So it seems quite natural to me to do that in the present case > as well. But your two malloc idea may seem more sane to those > without such historical Fortran experience. :-) > > Whatever I finally decide to do, I will be careful to define 2D array > types (like Phil's idea) to help discourage users from relying on > internal implementation details. > > 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 ------------------------------------------------------------------------------ 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
