Re: guile-user Digest, Vol 193, Issue 29

[Zelphir Kaltstahl <zelphirkaltstahl@gmail.com>]

On 26.12.18 20:51, Tk wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, 26 December 2018 12:43, Zelphir Kaltstahl <zelphirkaltstahl@gmail.com> wrote:
>
>> On 25.12.18 18:00, guile-user-request@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