Thank you for answering, Your digression about PDL was very much appreciated.
About the module I'm writing, the raw interface to the library is almost complete, but I need more time to work on the high level interface and right now I have little time, due to $job, so don't hold your breath :-) You wrote "You can still access it as a CArray if you allocate it yourself;"can you share any hint on how to make a CArray point to a Pointer? NativeHelpers::Blob doesn't seem to help, even if there are some ideas in there that might be adapted to the problem at hand. Thank you! On Thu, Sep 20, 2018 at 6:51 PM Curt Tilmes <c...@tilmes.org> wrote: > I haven't seen many responses to this yet. I am by no means a > MoarVM/NQP/Rakudo internals expert, speaking only as a developer on top of > those things, not inside them. > > On Sun, Sep 16, 2018 at 8:12 AM Fernando Santagata < > nando.santag...@gmail.com> wrote: > >> I'm developing an interface to libfftw3 (Fastest Fourier Transform in the >> West). >> The library provides a function to allocate SIMD-aligned memory (Single >> Instruction Multiple Data), in order to maximize access speed to data. >> Before I start to investigate a way to blandish a CArray into pointing to >> a stretch of previously allocated memory, how does Perl 6 allocate memory? >> Does it already use the SIMD alignment? >> > > I think efforts like this are important for Perl 6. Things like PDL were > 'tacked on top' of Perl 5, while I think with 'native' types, the long term > goal is to have such things more integrated. NativeCall,, 'is native', > CArrays, etc, have been huge steps in that direction, but I think there is > much work to go. > > I've had very good luck using NativeCall, keeping everything in C land, > and having in/out methods to transform things, but less luck trying to keep > the data structures straight between the two. That feels like the old PDL > way. I want to construct huge multi-dimensional arrays of native types in > Perl 6 and seamlessly call NativeCall functions on it (like fftw) and also > auto-parallelized, optimized Perl 6 operations for plain math. We're not > quite there yet. > > Something to keep in mind. If you allocate memory from Perl, the garbage > collector may move it around on you. Always get a fresh C pointer to it > just prior to passing to any NativeCall function. Another option is to > just allocate (and free -- you are responsible for it) from C, either with > some library allocation function, or just plain NativeCall malloc()/free() > and friends. It will never move around, and you can still use a bunch of > Perlish ways (Pointer, CArray, etc.) to read and manipulate it. > > I don't know the answer to your SIMD alignment question, but I suspect the > answer is no. If that is a requirement for your library (or performance), > you probably just want to allocate it yourself. You can still access it > as a CArray if you allocate it yourself. > > If you are doing some action heavily and find it slow, build a tiny test > case to illustrate and file a bug. That will give the folks with the > implementation knowledge some guidance for what would really help you. > > There is a lot of work still needed, but things have come very far already > and are moving fast. The fundamental architecture was designed to support > numeric work in the manner you will be doing, so there is a lot of room for > improvement, especially with multi-threading, long after Perl 5 PDL, NumPy > and friends have run out of gas. > > Since I'm here :-) will Perl 6 ever support a native type mirroring the >> __float128 quadruple-precision type provided by gcc? >> > > I'll wager that the answer to "ever support" is probably yes, as long as > somebody wants it. We're just waiting for the same person to be in the > "wants it" and "can do it" category at the same time. > > Curt > > -- Fernando Santagata
