On Sun, Dec 1, 2013 at 3:18 PM, Dima Kogan <[email protected]> wrote: > Chris Marshall <[email protected]> writes: > >> which suggests that it should work and that the crash is >> from some other place. Does the piddle data change >> alignment between one call and the next? If that were the >> case it might explain the problem. >> >> I think a feature request for improved memory allocation >> is definitely something of interest for PDL going forwards. >> >> However, it is invasive enough, low level, and very >> tricky to debug and get right so would need to be >> implemented and verified fully and extensively before >> any merge into the release PDL. If you had a branch >> with a work-in-progress, we could always push a >> CPAN developers release from that instead of master. >> >> If the problem is changing alignment in PDL (maybe from >> the make physical stuff), you might work around the >> problem by checking alignment and then correcting it >> at runtime if needed. > > Hi. > > First off, I'm certainly aware that I can fix this entirely within > PDL::FFTW3. I can make a new plan every time fft() is called. I can also > make a copy of the data. Or I can make a purposely-unaligned plan. This > would be needlessly inefficient, however. I want to do this right.
I would suggest that adding information on alignment to the plan reuse process should be sufficient. Of course brute force regeneration would be correct if inefficient. My point was that a correct plan reuse strategy that does not assume specific alignment would be generally applicable and correct. The problem of better alignment would then become an issue of performance optimization rather than having details of the PDL core internals determining whether or not PDL::FFTW3 works or not. Such robustness in the implementations makes the difference in whether PDL "just works" or not. > Second, I'm not yet pushing for any particular approach. I would like to > see how invasive aligning memory in PDL is to evaluate that. I was > hoping that deep in the core somewhere there's a malloc() call, and all > I have to do is to change it to a memalign(). It looks like it's not > quite that simple, but not all that far off. I now see three places. I > am now asking if there are more places people know about, and if those > three are indeed all relevant to data memory allocation. The three are: > > 1. pdl_malloc() in pdlcore.c.PL > 2. get_malloc() in CType.pm > 3. pdl_grow() in pdlhash.c > > Aligning the first 2 has no effect on the alignment, so I'm suspecting > the 3rd is main one. I think the approach Craig mentioned is the way to go for handling alignment internally to the PDL core code. As mentioned above, handling correctness of functionality within PDL::FFTW3 rather than in an additional requirement on the PDL core is more fragile and difficult to maintain. There could also be issues that come up as the work for the PDL2 to PDL3 transition gets underway. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
