SAVE attribute scope

21

Already done by @FedericoPerini:

stdlib/doc/specs/stdlib_linalg.md at 1d27d2734a6d4aedde16466dffcc5f167346b041 · fortran-lang/stdlib · GitHub

I agree with @jacobwilliams, we have been fixing everything about Fortran. Slowly, but surely. It does make me sad also that SciPy decided to remove Fortran.

Long time ago SciPy maintainers asked for a modern Fortran compiler (“if only we had a good modern compiler, it would fix many of our issues”). I said, no problem! We got most packages to compile with LFortran: LFortran Compiles 60% of Scipy - and I was excited that we will start collaboration with SciPy developers to bring this over the finish line and they will start using (or at least testing!) LFortran, which I think truly can fix all the tooling issues that SciPy had. But the only response we heard was “no thanks, we will only accelerate our move away from Fortran”. Had I known this would be the response, I would not spend so much engineering effort on the old Fortran, and rather focus solely on modern Fortran support that we need more. But I did this because I thought SciPy will collaborate with us, which would be a huge win. It would be a win-win. Instead we got lost-lost. We lost, and you lost.

Above you asked for a Lapack version in some array language other than F77. We are hereby giving it to you in modern Fortran.

I think the SciPy developers think they want something, they ask for it, we give it to them, but then they realize they don’t really want it. :slight_smile:

22

Oh I am paying a good attention to it. But you are missing out a fundamental detail, I want to rewrite LAPACK. Not to interface with it in a different way. I already have SciPy that does it if I need an interface. We cannot keep doing the same thing in the next 40 years. The codebase need to be touched.

Not sure why it became like this but this really makes me sad. I don’t know others but everytime there is a bashing needed, I stick my head out here to receive it.

Last thing I would want is to kill any enthusiasm in some other project. But just myself have repeated at least two times engaging with you, we have multiple problems and one of them is the tooling. I don’t think, we did not “ordered” a new compiler and cancelled the order midway.

We had and still have a lot of issues and a compiler is/was one of them. In fact it has been discussed here multiple times about Axel’s blog post. If we did not switch to meson and Flang was a thing, windows support was toast and lfortran was not fully ready at the time. So I don’t really think we sabotaged anything but if it became like so then once again my apologies.

We are not removing the need for a fortran compiler. The lapack wrappers are there for a very long time. So we will need a compiler anyways, but I think you are getting a bit impatient about the production readiness of LFortran. It is quite new and it will take some time to gather adoption from the non-fortran community. I still don’t understand how SciPy is the arbiter of things about Lfortran but we, or at least I, still promote it everywhere. Whether SciPy uses it or not should not be relevant for its success. Like I mentioned before there is a huge fortran codebase out there waiting to be compiled. Nobody would care if SciPy has fortran in it or not, in my outside opinion.

23

By the way, I hope it goes without saying but these are all my personal opinions and even inside SciPy I have received significant objections to these opinions I have laid out here. Hence please direct all criticism to me as an individual.

24

For the sake of completeness, Ondrej said it right - I did rewrite the whole of BLAS and LAPACK in a modernized, fully explicit and precision agnostic way: see ie

1 Like
25

Wait what? Why didn’t you promote this? Are you guys OK? Holy shit. If this is true what I am seeing, you guys don’t know how to announce things properly. Like is this some sort of a joke? And here you are busy talking about SciPy for good marketing. I mean come on.

Let me go and read this stuff. I’ll be back soon.

1 Like
26

@ilayn Maybe the promotion was not as loud as it could have been but there was a promotion here where @FedericoPerini first did a call to discuss about the API and modernization and then to announce the first batch of functionalities in stdlib:

New functionalities were added between the 0.6.0 and the current 0.7.1, some more are in the making. Keep tunned :wink:

1 Like
27

No no, you don’t get it. If I hear another SciPy comment, I’ll just ignore it from now on. You folks rewrote the most important Fortran piece worldwide and you call the forum posts as announcements? I hope you folks are being sarcastic.

Why don’t you contact Netlib folks to start with and then OpenBLAS and MKL team? Who gives a damn about SciPy? This is a big thing. You need to benchmark this and then the compiler should show its merits by giving a comparable result out-of-the-box. Why are you even caring about SciPy? I really don’t get you folks.

Anyways, let me read more, it’s your problem from now on.

Huge congrats to everyone involved by the way. Excuse the hyperbole, you need a good kick in the bunker by an outsider to wake up a bit I reckon.

1 Like
28

We have a great deal of tests in the CI. But regarding performance, the cleanest Fortran code won’t beat any processor-specific implementations that other languages allow.

What we do get from modern Fortran is the complete automation of the build system, and the complete generality (in ieee sense) of the implementation: just build the module file and don’t worry about architectures, build flags, macros, etc.

1 Like
29

It’s the language of scientific computing yada yada all the things constantly said about Fortran. Come on, you have done the hard part. Invite some HPC folks, go to SSE optimization people, get some help and push this over the line. If Fortran can’t, what can then? I won’t take this seriously

Stop bothering me I’m reading modern LAPACK heheh.

1 Like
30

@ilayn we are doing what we can. As a community we are writing a compiler, we are modernizing old codes and libraries, we are writing a package manager, maintaining a website, forum, etc.

The Lapack rewrite is new, it needs testing etc. We don’t want a reaction like this:

Oh, I know exactly our state. It’s alpha. It’s there on our front page, second paragraph:

image
image1170×96 11.3 KB

Rather, what I was hoping is to compile SciPy, and the SciPy community can help us getting it over the finish line with production readiness. Right now LFortran is alpha stage. But once it can compile something, I would call it beta quality for that particular project. To get it to production quality requires to be used by that project, report any bugs, we’ll fix them, etc. Somebody has to put in the work. I was hoping the SciPy community would do this work. :slight_smile:

It’s fine, we have compiled several more codes since then and eventually we’ll compile a code whose users will enthusiastically use the compiler and help us get it to production quality eventually. It’s just a matter of time at this point.

31

@cetik. I wouldn’t give up on SciPy. I know C well and it isn’t the right language for scientific computations.

32

Lfortran is new. LAPACK is not. Reference implementation makes bit-to-bit tests. You can start with their tests. It should be easy for folks who know Fortran. Then if you wrap it to any tool Octave, SciPy whatever and you can run their tests too.

These are mutually exclusive. Nobody will claim LAPACK rewrite is new. They will ask about performance and tests.

If you want to use Lfortran to compile the fortran code, then you will have resistance but if it works already open a PR and we can add to the backends already supported. Frankly, I don’t understand the bitterness.

How are we supposed to do this work in any meaningful way? We are trying to remove Fortran code because we don’t understand anything. This is not an expectation management issue on our side I’m afraid.

33

By using LFortran for the packages that work and reporting bugs. :slight_smile: It’s really simple.

34

I wonder if the arpack-ng maintainers would be receptive to an effort of modernizing the Fortran code? It’s not a totally abandoned Fortran 77 library, but maybe on life support (doesn’t look like they have made many code changes lately). Anybody want to take on this project?

1 Like
35

@jacobwilliams I can’t take it on, but I can confirm that arpack-ng has worked for me in the past for parallel eigensolvers. It’s a good package.

The other point I wanted to make is that even though it might seems that these modernization efforts (minpack, fftpack, other packs) are not worth it, because not many people seem to use the newer version, I see it as fixing technical debt, and a point will come (not too far off in the future), when people realize that can just “fpm-depend” on any of these (now maintained) high-quality libraries, and get an application bootstrapped real quick. It’s exciting!

2 Likes
36

This is a massive undertaking and long overdue. But I think it doesn’t change the problems SciPy developers face with LAPACK.

My understanding is the existing design of LAPACK just clashes with the broader SciPy requirements:

  • array views; LAPACK expects contiguous arguments (if you ask me is the only sane choice for performance reasons…), meaning they need to implement copying manually (if you stay in Fortran, the compiler does this for you)
  • default column major ordering of matrices; most people using NumPy just use np.empty((30,30)) and get C-ordering, forcing the Python wrappers to make copies or use transposed arguments.
  • integer arguments are 32-bit by default; having both 32-bit and 64-bit interfaces has proven problematic from the packaging point of view (strictly speaking this is not a problem in Fortran as generic interfaces could support both)
  • name mangling and other portability issues (e.g. argument order) related to the dozen of different LAPACK implementations out there
  • the requirement that the code by “f2c-able” so they can run it on platforms without a designated Fortran compiler (mobile phones, etc.); maybe this is just a NumPy problem, not a SciPy one.
  • lack of enthusiastic Fortran developers and maintainers
37

I think, better acceptance could be achieved if the rewritten libraries would

  • offer F77 wrappers around the new routines, which are compatible with the old ones
  • be offered (also) as separate packages and not being buried within stdlib (although, it is a good idea if stdlib offers those as well).

DFTB+ for example depends on both LAPACK and ARPACK (arpack-ng). I really would not like to depend on stdlib. I really would not like to depend on a newly rewritten library with a new interface, where long term maintainance is questionable. I really can not use fpm for a project of that size and complexity (yet), so I won’t profit from the availability of the new library for the fpm universe. In contrast, arpack-ng is available on Conda and is part of various Linux distros as well, so whoever wants to build DFTB+, can satisfy this dependency easily.

If the rewritten library offered also the legacy interface, anybody could try it as a drop-in replacement. If it turns out to be more performant, being better maintained, etc., probably many of us would consider to use it exclusively and then even upgrade to the modern interface.

2 Likes
38

It will not take anything away from this achievement but are these SPAG or similar tool output by any chance? I am trying to make sure I am looking at the right thing. Because I know some fixes are applied to OpenBLAS but I don’t see it here so just trying to make sure how the source is handled.

Any work done on LAPACK is a net win. We can adapt to any improvement from the SciPy side. I agree with your points though. LAPACK should be available in multiple languages in my opinion.

39

We addressed this in our modernized LAPACK by generalizing the integer kind, so, one can build a reference implementation with either 32 or 64-bit integers just by changing the ilp kind flag. A PR is ongoing to automate this when an external MKL requires it, but I don’t see why it couldn’t be just templated out (aka 2 versions for each routine, supporting either integer kind).

The LAPACK license requires us to change routine names, and the change be documented. So we just prefixed our whole implementation with stdlib_*. But we engineered the code such that the original interfaces are 100% still available, but now generalized (c, z s d initials dropped). So if one has a code using the F77 interface, just drop the initials and it will just work using either the modernized implementation or a linked external library. Let me stress that I’m talking about the original LAPACK interface, not only the high-level “NumPy-like” APIs.

I had the same thought and started it as a separate library+interface with no other dependencies. The community request was that it’d be part of stdlib. I very much like having it in stdlib, it has no external dependencies so its build process is straightforward (you could use CMake or just pick the stdlib-fpm branch)

Regarding LAPACK, there is both a high-level (“NumPy”) API and the old-style F77 API is still 100% supported via kind- agnostic interfaces (e.g., call gesv instead of call dgesv, call cgesv, call sgesv). The interfaces are useful because they ensure all KINDS are always supported (32,64,80,128 bits) so no macros are needed, and they cherry-pick an external library if that is linked against (so you may have a 32-bit Accelerate library, but then also use a 128-bit gesv interface: no edits needed to the code at any times).

I’m with you - in my case, I don’t have the time and resources to refactor my large projects to fpm’s strict folder structure, but this is how package managers work: they target large ecosystems of small self-consistent libraries rather than large complex projects.

For LAPACK, you can :slight_smile: do not hesitate to ask for help on github, here, or via DM.

PS: thanks to @hkvzjal stdlib is on Compiler Explorer, it’s a great place to see how the interface works - there are quite a few examples available.

No, they were forked from LAPACK 3.10.0 using a custom Python script. We’ve already been addressing some bugfixes in the original code, so, the current implementation is forking out of it already.

2 Likes
40

Ah OK, we had a similar script too (a version of crackfortran from f2py) so you also have some machine-generation involved, thanks! Our version is 3.12 so probably that’s why.