1 |
Hi Gentoo Science team, |
2 |
|
3 |
In the sci overlay there is a long existing feature "int64" for the |
4 |
BLAS/LAPACK packages, with which the type of array index in the |
5 |
API/ABI will be changed into int64_t so that BLAS/LAPACK libraries |
6 |
could be able to handle super large arrays. The reason of existence |
7 |
of such feature stems from a Fortran compiler feature which could |
8 |
change the default INTEGER size (e.g. 32bit, 64bit). |
9 |
|
10 |
Recently the BLAS/LAPACK runtime switching mechanism has been merged |
11 |
into ::gentoo, but you may find no counterpart to the "int64" feature |
12 |
existing in ::sci. According to previous discussion, we could indeed |
13 |
add a new alternative group called, for example, BLAS64 and LAPACK64. |
14 |
However, it must be pointed out that, even if the "BLAS64" thing is |
15 |
well supported by commonly used optimized implementations such as |
16 |
BLIS, OpenBLAS, and MKL, the 64-bit-indexing feature is not well |
17 |
supported by the reference CBLAS. Even worse, there is no common |
18 |
standard for such "BLAS64" and "LAPACK64" libraries in terms of |
19 |
ABI and SONAME. That means every move on the "BLAS64/LAPACK64" |
20 |
runtime switching mechanism will be highly experimental and |
21 |
may easily be broken by the authorities who define standards. |
22 |
|
23 |
Before I started the GSoC project for Gentoo I had already started |
24 |
working on adding BLAS64/LAPACK64 alternatives. We Debian science |
25 |
team thought it's fine to experiment even if there is no standard |
26 |
at all. Exactly due to this reason, the 64-bit-index feature wasn't |
27 |
put on the original GSoC schedule. I thought we could first |
28 |
experiment it on Debian. |
29 |
|
30 |
However, now we have to face the problem again because some packages |
31 |
such as Julia require the 64-bit-index ABI. (ah, yes, I was aware of |
32 |
this since I also maintain Julia for Debian). Combining the fact that |
33 |
there is no standard (even de-facto standard), and the demand of |
34 |
some packages such as Julia, Benda and I reached an agreement that |
35 |
we could simply add 64-bit-index support for OpenBLAS and postpone |
36 |
the runtime switching feature for BLAS64/LAPACK64. |
37 |
|
38 |
Julia calls BLAS64 and LAPACK64 through FFI. Theoretically Julia |
39 |
could use any BLAS/LAPACK implementations but actually Julia's |
40 |
LinearAlgebra standard library is not quite ready for such a |
41 |
switching feature. Hence Debian's Julia package is actually |
42 |
specifically linked against libopenblas.so (32-bit) and it is |
43 |
irrelevant to the runtime switching feature. Afterall there is |
44 |
no problem by forcing Julia users to use OpenBLAS. |
45 |
|
46 |
In a word, what Benda and I plan to do are: |
47 |
|
48 |
* add index-64bit USE flag to openblas, which compiles an extra |
49 |
libopenblas64.so for Julia's use. |
50 |
* postpone the plan for BLAS64/LAPACK64 runtime switching, and |
51 |
experiment on Debian first. |
52 |
|
53 |
That said, if anyone believes the BLAS64/LAPACK64 feature is sort |
54 |
of urgent need, we can discuss further and revise the plan again. |
55 |
|
56 |
Thanks. |
57 |
|
58 |
See also: |
59 |
[1] the 64-bit-indexing feature has been postponed by |
60 |
reference lapack upstream: |
61 |
https://github.com/Reference-LAPACK/lapack/issues/184 |
62 |
|
63 |
|
64 |
On 2019-07-11 13:59, Benda Xu wrote: |
65 |
> Hi, |
66 |
> |
67 |
> This discussion emerged from https://github.com/gentoo/sci/pull/876. I |
68 |
> am taking it here for better future reference. |
69 |
> |
70 |
> cdluminate: |
71 |
>> It would be problematic to provide int64 ABI/API through libblas.so or |
72 |
>> liblapack.so since that would lead to a mess with the int32 |
73 |
>> ABI/API. Adding the int64 USE flags to existing packages will make it |
74 |
>> hard to write ebuilds for users who want e.g. both int32 and int64 |
75 |
>> openblas at the same time. My personal recommendation is to provide a |
76 |
>> new set of packages, say eselect-{blas64,lapack64} + sci-libs/lapack64, |
77 |
>> which are clearly isolated with the int32 ones. These new packages |
78 |
>> should change SONAMEs into say libblas64.so and liblapack64.so. This is |
79 |
>> the same as what I'm doing for Debian's 64bit-indexing BLAS/LAPACK |
80 |
>> packages. |
81 |
> |
82 |
> heroxbd: |
83 |
>> We can make int64 as a use flag and by enabling it we install 2 sets of |
84 |
>> libraries: libblas.so and libblas64.so. What do you think? |
85 |
> |
86 |
> kiwifb: |
87 |
>> I know why you want that @heroxbd - you want to avoid ebuild |
88 |
>> duplication. On the face of it it is less ebuilds to maintain in |
89 |
>> exchange of more complex ebuilds. However I think it would still be |
90 |
>> wise to have at least separate virtuals - that means dependencies on |
91 |
>> int32 and int64 are completely separate and allow a different set of |
92 |
>> implementations without impinging on each other. |
93 |
> |
94 |
>> Whether to go for doubling the ebuilds or making them more complex is |
95 |
>> up to the maintainer. And we have to deal with the headers in any |
96 |
>> case. |
97 |
> |
98 |
> cdluminate: |
99 |
>> I agree with @kiwifb . At least we need |
100 |
>> virtual/{blas64,cblas64,lapack64,lapacke64}. For the implementations |
101 |
>> we could introduce two new USE flags: int32 and int64, where each of |
102 |
>> them could trigger a separate full build, and int32 is enabled by |
103 |
>> default. Same for the eselect packages. |
104 |
> |
105 |
> I agree with int32 and int64 USE flags. but int32 and int64 is too |
106 |
> simple and misleading, how about index_int32 and index_int64? They are |
107 |
> named after python_targets_python3_7. |
108 |
> |
109 |
> Virtual/blas could do the same: virtual/blas[index_int32,index_int64]. |
110 |
> |
111 |
> Yours, |
112 |
> Benda |