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
