On 26.12.18 20:51, Tk wrote: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, 26 December 2018 12:43, Zelphir Kaltstahl > <zelphirkaltst...@gmail.com> wrote: > >> On 25.12.18 18:00, guile-user-requ...@gnu.org wrote: >> >>>> Hello Guile Users, >>>> Is there some library, that enables high performance matrix operations >>>> or even n-dimensional array operations? I am thinking of something like >>>> NumPy in the Python ecosystem. I think NumPy in turn also uses some >>>> lower level thing to do what it does. I think OpenBLAS or MKL, depending >>>> on the architecture. I wonder if there is any wrapper around OpenBLAS >>>> for Guile or something similar. >>>> I am writing a little code for matrix operations and currently I am >>>> using Guile arrays, as they are made of vectors and have constant access >>>> time, which is already great. My guess is, that this would be the right >>>> choice if using pure Guile. I am writing data abstraction procedures, so >>>> that later on I could exchange what is used to represent the data. >>>> Maybe, if there is something like NumPy or lower level, I should use >>>> that instead? (Would I have to learn how to use FFI first?) >>>> Or maybe Guile's implementation is already so fast, that it would not >>>> make that much difference to use a lower level thing? >>>> Currently I have only a little experimental program, started today, so >>>> no huge plan. OK, one can fantasize about stuff like Pandas data frames >>>> in Guile, but I have no illusion, that it is a work of a few days or >>>> even weeks. It would be nice to learn, how to use a low level thing or >>>> maybe even Pandas, if there are any such bindings for Guile. I could >>>> make the implementation use different representations, depending on a >>>> parameter or something like that. >>>> Regards, >>>> Zelphir >>>> I took a different route. Instead of merely binding functionality in a >>>> lower level language, I use Guile to generate lean-and-mean modern Fortran >>>> code. The building blocks can be found here: >>>> https://gitlab.com/codetk/schemetran (wanted to save this for potluck, but >>>> here it goes ... ). Fortran compilers take care of efficient execution on >>>> HPC platforms. Actually, it is beyond me why anyone would bother with any >>>> other programming language when it comes to expressing maths efficiently. >>> I built a pseudo-spectral Navier-stokes solver that can work on MPI, >>> shared-mem (OpenMP), and hopefully soon GPU/Xeon accelerators (OpenMP 4) >>> atop of schemetran. I still need to see about publishing it under an Libre >>> licence. >> Hi Tk, >> >> That looks interesting. I've only used OpenMP once in a university >> lecture, in a pretty simple way (just adding some annotations to some >> loops to parallelize them) on a normal desktop machine. I have a few >> questions about your library: >> >> What are the requirements in terms of installed software? (For example: >> Do I need something Fortran installed? Or is GCC handling it all?) >> >> What do you mean by "on HPC platforms"? Does that imply, that it would >> not produce efficient execution on desktop machines? >> >> Thanks for sharing your project, I will have to take a look at how to >> use it. >> >> Regards, >> >> Zelphir > > Hi Zelphir, > > The requirements are guile >=2.0, fortran compiler that understands bits of > 2003/2008 standards used in the "library" (which should rather be thought of > as a set of lego pieces) and GNU Make. The oldest gfortran compiler that I > know works for certain with schemetran is gfortran 4.8.2. As for Intel, I've > only tested it with v17 and greater, but I'm fairly confident anything >v13 > should work, too. In addition, I ran tests with flang 7.0.0 (from clang/AOCC > suite) and that suprisingly worked, too (suprisingly because they claim they > fully support only Fortran 2003). > > > Schemetran itself is for the moment only helping you write pure Fortran code. > So, no OpenMP directives are currently included. This was a design decision, > because compiler directives, even when standardised, are dirty. I have some > plans in that direction, but this will be something separate from schemetran > (once I pull it from the guts of my incompressible MHD code). > That being said, schemetran can be used to generate coarray fortran (part of > 2008 and later standard extensions) which current fortran compilers usually > implement on top of MPI parallelism (at least, that used to be the case when > I last looked into this). > > Some fortran compilers (say, Intel Fortran) can auto-parallelise your code > even if coarray extensions are not used. This is almost always done using > threads. > > Even if a compiler doesn't generate parallel code, it should be able to > efficiently optimise array operations so that all vector based capabilities > of present day processors are properly exploited (SSE, AVX). Some care needs > to be taken when writing code that compilers can recognise as SIMD > vectorisable and schemetran helps you with that (chiefly by not > overcomplicating things much). > > I realise I deviated from your questions a bit, so let me get back on track. > Yes, all of the things mentioned can run on a normal CPU. Vector instructions > such as SIMD can be used anywhere, OpenMP on any multicore CPU (so, > realistically anywhere these days), even MPI which was designed for > distributed computing can be used on a single CPU (since mainstream MPI > distributions try hard to turn your message passing into shared memory > accesses behind your back). > > Hope this helps, > > Todor > > > PS Nothing prevents you of adding OpenMP statements by hand into the mix by > modifying some of the schemetran directives. > > PPS I hope nobody on Guile mailing list is going to shoot me for advertising > Fortran as a scientific language of choice ;-P . > > PPPS For those guys who want ndarray functionality in Guile .. do you > actually intend to write complicated algebraic expressions using LISP-like > notation? That's brave. I hope no nuclear facility melts down as a > consequence of someone messing up transcription of normal math into brackets > :) . > Thanks for all that info. It certainly seems like an interesting project.
I am not sure it would be less work using it, compared to interfacing with CBLAS though for example and I don't think I could figure out most of the performance optimizations, that is already in BLAS or ATLAS. I guess I would use you project, when I have something that is not plain matrix multiplication and still want to have Fortran level parallelization. As I can see from all the responses, there are quite a few options and now I am not sure what I should use. I will have to try a few things. Regards, Zelphir
