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. 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. dima _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
