Hi Jim: On 2015-01-26 12:02-0500 Jim Dishaw wrote:
> As Phil points out, this is a minor performance optimization because the difference in a 2 ms memory allocation vs and a 0.07 ms memory allocation is not significant given the number of 2D allocations a typical program would make. I'm always astonished by the multiple allocation approach, but that may be an artifact of my programming background (realtime and distributed computing). In light of what Phil said and the relatively minor speed advantage in the PLplot case I understand your decision not to move forward with your idea of improving the efficiency of the implementation of plAlloc2dGrid at this time. <important ephcom question> However, the ephcom subproject of timeephem (which like PLplot is licensed under the LGPL) uses two routines ephcom_Alloc2dChar and epchom_Alloc2dDouble (which you can see at <https://sourceforge.net/p/timeephem/timeephem/ci/master/tree/ephcom/src/libs/ephcomc.c>) that are very similar to plAlloc2dGrid (because I implemented them following what is currently done for PLplot). Would you be willing to give your official permission to adapt your new approach for the needs of ephcom under the LGPL? For that case efficiency really is a big deal. For example, I have one application where the ephcom interpolation routines are called every 0.5 days for an ephemeris with an epoch range of 30 000 (!) years. So that is 22 million calls to the 2d allocation routines for chars and doubles and the equivalent free2d routines and the difference between 2 ms and 0.07 ms suddenly starts to matter a whole lot! If you do give your permission, then I plan to significantly change the API as well (which doesn't require much soul-searching in the ephcom case because we haven't built up a big following yet, and for the next release the ephcom API is going to be massively changed in any case). In particular, I plan to change ephcom_Alloc2dChar and epchom_Alloc2dDouble to one routine that uses the following "void-pointer style" API: void **ephcom_malloc2d(size_t nx, size_t ny, size_t pointer_size, size_t value_size); where the routine returns NULL if there is a memory allocation error, and otherwise a void pointer to a pointer which can be cast to (char**) or (double**) as needed. nx and ny are the number of x and y elements in the 2D array, and pointer_size and value_size would be sizeof(char*) and sizeof(char) in the char** case and sizeof(double*) and sizeof(double) in the double** case. And the current ephcom_Free2dChar and ephcom_Free2dDouble routines would be completely dropped and a call to free would be used instead. Also, I would define an ephcomCHAR2d and ephcomDOUBLE2d type to help indicate that users should not rely on internal implementation details of the above ephcom_malloc2d function. Also, in the ephcom case there is no use for resizing any of these 2d arrays so I would not provide an API for that. </important ephcom question> > To summarize what I intend to do. I will keep the current implementation and move the routines to a new file called plmem.c I really like the PL_FLT_ARRAY2D idea because it provides better context to the user of the plplot library. However, I won't make the change at this time. For the PLplot case, I also like Phil's PL_FLT_ARRAY2D idea. I look forward to seeing your "plmem.c" patch which I plan to test and push to the master branch on our server. 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
