blis
blis copied to clipboard
flame
implement Fortran 2003 interface module for BLIS C API
Modern Fortran provides an elegant way to wrap C. Implementing an interface module for BLIS would make it much more appealing to Fortran applications that do not want to use legacy APIs like BLAS, which are based on "ancient" Fortran.
Related https://github.com/flame/blis/issues/264
@fgvanzee This should be completely independent of BLIS in its implementation. Whether it lives in the BLIS repo or not is your decision. For now, I will create a separate repo since we may want to keep Travis CI independent to avoid having to debug Fortran issues in the main BLIS Travis CI setup.
The way Fortran-to-C works is there is a Fortran interface module that knows the C signatures of every BLIS function. A Fortran user compiles this with their Fortran compiler then does use blis in their Fortran code. The BLIS module will be able to type-check calls to BLIS from Fortran as well as allow pass-by-value semantics. This eliminates the need to do a shim where one writes an interposition C function that translates arguments from reference/pointer to value.
The ParaTools i.e. TAU team has a Fortran 2003 wrapper generator that may be useful here. I will discuss with them offline.
Yes, for modern Fortran interfaces. They really should be modern Fortran though, rather than an f77-ish thin interface to C. Is there any overlap with what libxsmm has, which I've not looked at? This should ideally go with interfaces for BLAS; MKL has defined interfaces, but they're non-free (assuming they're really copyrightable). Is there any chance of freeing them as a de facto standard, perhaps? Could an Intel person could use the tool that created them, which looks more sophisticated than a simple interface generator?
@loveshack Honestly, if I was going to create a modern Fortran interface for the BLAS, I would just create a Fortran 2003 module for the CBLAS, because then I would know how many bits were in an integer without having to resort to divination.
I honestly haven't looked at what LIBXSMM or MKL has done here though. There are only so many hours in the day and there are people paid to worry about MKL and LIBXSMM already, so I choose to devote my linear algebra development cycles to BLIS.
...so I choose to devote my linear algebra development cycles to BLIS.
For which we are deeply grateful. :)
There is an automatic tool based on SWIG to generate Fortran 2003 wrappers for C/C++ that we are working on. The source code is located here. If this is something you may be interested in, please let me know. It's pretty complete at the moment, especially for C (it also allows wrapper generation for C++).
ParaTools also responded favorably, so I will try both and see what makes more sense.
@loveshack Honestly, if I was going to create a modern Fortran interface for the BLAS, I would just create a Fortran 2003 module for the CBLAS, because then I would know how many bits were in an integer without having to resort to divination.
I don't get that. All I should have to be concerned with in Fortran is the KIND.
I honestly haven't looked at what LIBXSMM or MKL has done here though. There are only so many hours in the day and there are people paid to worry about MKL and LIBXSMM already, so I choose to devote my linear algebra development cycles to BLIS.
I wouldn't be suggesting anyone works on MKL, but I know you had worked on MKL re-licensing, and might be able to get something useful from it freed to avoid re-invention for use by BLIS and other implementations.
I'm sorry if BLIS isn't interested in potential (in)compatibility with existing work; I don't know if there is any overlap with libxsmm, but if there is, it's likely to be relevant specifically for other programs in ELK's area. It's bad enough having to support BLAS implementations that seem to be working basically the same way independently without add-ons potentially having different interfaces. I might have been prepared to look into it.
@loveshack
All I should have to be concerned with in Fortran is the KIND.
Given a binary library libblas.a, how does one tell whether an integer width promotion flag (e.g. -i8) was used to compile it? In contrast, the width of C int is defined by the platform, not the compiler. This is why I want to wrap CBLAS instead.
...I know you had worked on MKL re-licensing, and might be able to get something useful from it freed to avoid re-invention for use by BLIS and other implementations.
Software licensing changes in a corporate environment are more complicated than you might think.
@fgvanzee This should be completely independent of BLIS in its implementation. Whether it lives in the BLIS repo or not is your decision. For now, I will create a separate repo since we may want to keep Travis CI independent to avoid having to debug Fortran issues in the main BLIS Travis CI setup.
The way Fortran-to-C works is there is a Fortran interface module that knows the C signatures of every BLIS function. A Fortran user compiles this with their Fortran compiler then does
use blisin their Fortran code. The BLIS module will be able to type-check calls to BLIS from Fortran as well as allow pass-by-value semantics. This eliminates the need to do a shim where one writes an interposition C function that translates arguments from reference/pointer to value.The ParaTools i.e. TAU team has a Fortran 2003 wrapper generator that may be useful here. I will discuss with them offline.
I would request that the interface not be too complicated. Most of the physicists who use Elk are not expert coders. They also have to compile codes, without root access, on servers which are set up according to the whims of the system admins.
A simple interface à la MKL, with subroutines/functions callable from Fortran 90 would be ideal.
I would request that the interface not be too complicated. Most of the physicists who use Elk are not expert coders. They also have to compile codes, without root access, on servers which are set up according to the whims of the system admins.
A simple interface à la MKL, with subroutines/functions callable from Fortran 90 would be ideal.
My intent to map directly to the BLIS C API. If you want something simpler, it can be built on top of this. And please don’t let my plan from preventing you to do something similar or different.
My intent to map directly to the BLIS C API.
Sounds absolutely fine. I guess that will involve some variables passed by value, fortunately this can be done as standard in Fortran 2003.
@jkd2016 Yes, that's exactly why I want to use Fortran 2003. It's obnoxious to write a two-level wrapper to deal with pass-by-reference semantics.
Hello! I would like to use the mixed precision procedure "bli_gemm" in my Fortran code. Is this not possible yet?
@peterukk as that isn't part of the BLAS interface, I don't think anyone bothered to write Fortran wrappers for it. If you want to contribute this feature, look at frame/compat for how it is done for BLAS functions.
I am sorry that I haven't written the Fortran 2003 interface yet. I tend the queue these things up and then get busy with my day job and not come back to them until reminded.
@jeffhammond ping. I'm loath to close because it might actually get done someday :smile:.
Leave it open. Some of my finest work is done in response to public shaming. I don't know when I'll have time for this but I might take vacation in December.
BigMPI exists because Andreas Schäfer wrote a blog post quoting Pavan Balaji saying that I was going to fix it, which I had discussed with Pavan but not actually implemented. Andreas' blog was quoted in HPCWire, at which point I figured I had to follow through.
I've launched an attempt to implement the interface modules using the fypp preprocessor here: https://github.com/ivan-pi/blis-f. If anyone wants to help, feel welcome to contact me.
