Support 64-bit BLAS and LAPACK (ilp64)

[ViralBShah]

It would be nice to have support for 64-bit BLAS and lapack (ilp64). We are running into this issue in the Julia project, where we are building various Coin-OR libraries, and our default BLAS setup is 64-bit.

[tkralphs]

Hey @ViralBShah nice to see you here. This has not been on our radar, will try to take a look at what's involved, but our list of urgent TODOs is pretty long. Out of curiosity, what are you guys doing with COIN-OR? I guess you are aware of JuMP. We've worked pretty closely with them on making COIN-OR available in Julia.

[ViralBShah]

@tkralphs Thank you for the quick response! Yes, this is certainly part of JuMP. The main reason I am looking into these builds is to help migrate from our old system of providing binaries to our new binary artifacts system. As a result, I was looking deeper into the way we build these libraries for Julia users.

JuMP currently uses CLP which links to CoinUtils, which in turn links to the reference BLAS and LAPACK. I am working throughout the Julia ecosystem to ensure that we use a fast BLAS everywhere. This is made difficult due to the fact that Julia itself ships with a 64-bit ILP64 BLAS (all integers and integer arrays are 64-bit). In order to avoid accidents, we mangle the names of BLAS and LAPACK functions adding the nowadays commonly adopted suffix _64. As a result we end up patching some libraries that assume a 32-bit LP64 BLAS, where it is easy to do so.

There are two solutions for us. One is to ship a 32-bit LP64 BLAS and LAPACK for 64-bit platforms on Julia, which I prepared yesterday, and if all goes smoothly, it should just work. The other solution is to have some tooling in CoinUtils to support 64-bit LAPACK. I noticed that only the LAPACK functions dgetrf and dgetrs are used, and we could have a simple wrapper that dispatches to either a 32-bit or a 64-bit version. I was prototyping something like that yesterday which I am putting in a gist.

I noticed that the build on CoinUtils master is a lot cleaner than the latest release with clean output, and better checking in the configure scripts. Nice improvements for people who are poking into the build system!

[tkralphs]

OK, I just reviewed the discussion on JuliaPackaging/Yggdrasil#694. Wow, I was unaware that you guys were looking so intensively at CoinUtils and were wrestling with it. We should definitely coordinate, as there is stuff going on over here that you should probably be aware of. I'm happy to answer questions as needed. I'm glad to see @dpo involved, though!

Perhaps most importantly, the build system has changed extensively just recently (as you noticed, thanks!). @giordano mentioned that we don't package the m4, which is true. All COIN-OR package share the same m4, which is maintained here. However, until this recent update, we were stuck on very old version of the auto tools due to a bunch of patches and bug fixes we made that only worked with those old version. We now went through the painful process of re-implementing the whole build system and it now works with recent versions. We'll continue to stay current going forward. It's all much easier to maintain now. We don't list BuildTools as a dependency anymore in the Dependencies, but maybe we should, or at least document where the m4 lives and how to work with the build system.

With that said, I wouldn't put too much effort into overcoming any idiosyncrasies of the old build system (i.e., the ones used in stable/2.11). Once we got a bit more housekeeping done, We'll be shipping a new stable version that will use the new build system and I think that will make life easier.

Some other questions I saw in the thread:

• It was mentioned somewhere in that earlier thread that one could try building CoinUtils without BLAS/LAPACK and this can be done, but Cbc/Clp will take a performance hit in this case.
• It was also questioned whether Glpk is useful. We use it only for its capability to read AMPL/ GMPL model files and this would not likely be relevant with JuMP available.

I'm curious about the big picture here. Is this effort just because of JuMP? Or is CoinUtils useful to you in some other way? If it's because of JuMP, then I assume you will be working up the stack, which means you should be thinking about projects other than CoinUtils (i.e., Clp). Just looking quickly there, it seems Clp also uses only dgetrf and dgetrs, but if you are looking at porting the whole stack, you should also look there.

If you start working up the stack, you might also want to leverage coinbrew, which makes it easy to fetch COIN-OR projects with all the correct dependencies and build them one by one.

[ViralBShah]

I should point out that I am literally only building the binaries, but am otherwise not a user of the solvers myself, and @odow and @mlubin may be better placed to talk about the JuMP ecosystem and what all it needs. I'm just chipping in with the new way in which Julia is now shipping libraries through its artifacts system.

My main goal was to support the JuMP solvers, while having all the high performance dependencies plugged in the right way. That was mainly how I started looking into CoinUtils myself. JuMP is using CoinBLAS/CoinLAPACK, and hence I think that those solvers are probably slower than they should be. I did learn yesterday looking through CoinUtils that GLPK is only for reading files, so unless the JuMP team wants it, we don't need to include it. We do have GLPK packaged up though the new Julia artifacts system, and @odow is using it in GLPK.jl.

I eventually ended up packaging CoinUtils 2.10.14 (although I think that build file will work for 2.11.x as well). I learnt that small point version differences tend to break packages, and hence to keep things straight, I am using the exact versions that JuMP uses currently. We ended up providing an OpenBLAS32 so we don't need to patch for 64-bit BLAS, which made things a lot easier for the moment, and will be useful in many other non-COIN libraries as well.

Thanks for the pointer to coinbrew. That will help as we package all the things up. The current plan I am following is to bundled up each dependency individually. The Julia artifacts system can now hold different versions of the various libraries we need, which allows for a systematic upgrade process going forward.

I agree that putting effort into the old build systems is not worthwhile. We've got it building for the moment, and I am sure we'll get it working. The build system on master felt a lot more streamlined, and it would be nice to be able to link openblas64 and 64-BIT BLAS in general.

[tkralphs]

Sounds good, I'll leave this open for now and maybe we can try something like what is in your gist to be able to link to 64-bit BLAS. If you start working up the stack, these homebrew recipes might also serve as templates for how everything fits together.