On Sun, May 06, 2018 at 08:29:29AM +0000, Lumin wrote: > > He put forward a simpler solution: Just don't provide libblas.so.3, such > > that MKL will never be used to satisfy the dependency of libblas.so.3 . > > Based on his idea, my new solution is the follows: > > > > libmkl-rt -- > > Depends: libblas3 | libblas.so.3 > > Provides: NOTHING ... (4) > > > > So it's totally safe now. If there is MKL, there must be a free > > libblas.so.3 implementation with a priority definitely larger than 1, > > overriding MKL in terms of auto-mode alternatives. On the other hand, > > if that alternative is manually set, then there is nothing to worry > > about. This solution is also able to resolve problems found in (1) and (3). > > Now libmkl-rt doesn't provide libblas.so.3 and liblapack.so.3, and it > pre-depends on libblas3 | libblas.so.3 and liblapack3 | liblapack.so.3 . > Similar change was applied to libmkl-dev.
Using a Pre-Depends here is IMO wrong. Quoting Policy §7.2: Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress. You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached. See Dependencies. I also think that removing the Provides is not a good idea. The alternative is provided by the package, and that should be made clear in the dependency relationships. I'm sorry but I don't have an ideal solution to the problems we previously discussed. But IMO it's acceptable to not perfectly deal with the corner case where only MKL is installed, as long as some warning is displayed. > Previously Sébastien expressed his interest on benchmarking. I'm > interested in that too. So apart from the debconf part, I wrote a simple > benchmarker[4] in Julia[5] for comparing several BLAS implementations. > Thanks to Julia's convenient FFI functionality, I can test all > implementations within a single run, without any modification to environment > variable or alternatives. > > Test result on my laptop (CPU=i5-7440HQ) matches expectation: > > dnrm2 Julia > 0.000033 seconds > dnrm2 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0 > 0.000074 seconds (3 allocations: 48 bytes) > dnrm2 Error :1.1368683772161603e-13 > dnrm2 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 > 0.000038 seconds (3 allocations: 48 bytes) > dnrm2 Error :0.0 > dnrm2 /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so > 0.000031 seconds (3 allocations: 48 bytes) > dnrm2 Error :0.0 > dnrm2 /usr/lib/x86_64-linux-gnu/libmkl_rt.so > 0.029561 seconds (3 allocations: 48 bytes) > dnrm2 Error :0.0 > dgemm Julia > 4.362279 seconds (2 allocations: 128.000 MiB, 0.20% gc time) > dgemm /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0 > 47.893710 seconds (10 allocations: 160 bytes) > dgemm Error :2.0735139719127268e-10 > dgemm /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3.10.3 > 10.412422 seconds (10 allocations: 160 bytes) > dgemm Error :2.4175670445887973e-11 > dgemm /usr/lib/x86_64-linux-gnu/libopenblas_haswellp-r0.2.20.so > 1.211220 seconds (10 allocations: 160 bytes) > dgemm Error :2.770610675980814e-11 > dgemm /usr/lib/x86_64-linux-gnu/libmkl_rt.so > 1.103356 seconds (10 allocations: 160 bytes) > dgemm Error :2.7982744719588258e-11 > > Netlib is always the slowest one. For small matrices OpenBLAS is > very competitive. For large matrices MKL is the fastest. Thanks, this is an interesting data point. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
signature.asc
Description: PGP signature
