libmir/mir-blas

NDSLICE wrapper for BLAS

mir-blas's Issues

ldd-link error when building with dub against MKL-Intel

I would like to use gemm function from mir-blas in the dub project.
Downloaded and installed Intel MKL library for Windows: https://software.intel.com/en-us/mkl/choose-download/windows

dub.json

"dependencies": {
	"mir-algorithm": "~>3.7.18",
	"mir-random": "~>2.2.11",
	"mir-blas": "~>1.1.9"
},

dub.sdl

name "d_benchmarks"

subConfiguration "mir-blas" "mkl-sequential"

lflags "/LIBPATH:C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\mkl\lib\intel64" platform="windows-x86_64-ldc"
lflags "/LIBPATH:C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\mkl\lib\ia32" platform="windows-x86-ldc"

But running $ dub build --compiler=ldc2 throws the following error:

mir_benchmarks>dub build --compiler=ldc2
Performing "debug" build using ldc2 for x86_64.
mir-core 1.1.0: target for configuration "library" is up to date.
mir-algorithm 3.7.18: target for configuration "default" is up to date.
mir-blas 1.1.9: target for configuration "library" is up to date.
mir-linux-kernel 1.0.1: target for configuration "library" is up to date.
mir-random 2.2.11: target for configuration "default" is up to date.
app ~master: building configuration "application"...
blasint = long
lld-link: error: undefined symbol: __security_cookie
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(dgemm)
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(dgemm)
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(dgemm)
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(dgemm)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_printf_s)        
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_printf_s)        
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_fprintf_s)       
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_fprintf_s)       
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_fprintf_stdout_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_fprintf_stdout_s)
>>> referenced 255 more times

lld-link: error: undefined symbol: __security_check_cookie
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(dgemm)
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(dgemm)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_printf_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_fprintf_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_fprintf_stdout_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_vfprintf_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_vfprintf_stdout_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_sprintf_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_vsprintf_s)
>>> referenced by mkl_core.lib(mkl_libc.obj):(mkl_serv_vsnprintf_s)
>>> referenced 92 more times

lld-link: error: undefined symbol: __GSHandlerCheck
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(.xdata)
>>> referenced by mkl_intel_ilp64.lib(_dgemm.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced by mkl_core.lib(mkl_libc.obj):(.xdata)
>>> referenced 94 more times
Error: linking with LLD failed
ldc2 failed with exit code 1.

Am I doing everything correctly?

Circle CI failure

Not currently able to build docs

Either git or ssh (required by git to clone through SSH) is not installed in the image. Falling back to CircleCI's native git client but the behavior may be different from official git. If this is an issue, please use an image that has official git and ssh installed.
Cloning git repository

error cloning repository: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

`symm` with mixed strides in B/C

The symm function doesn't seem to do a good job at handling mixed strides in matrices B and C. This arises when you want to evaluate A*B where B is assumed to be symmetric an A is the result of a transposed operation. It isn't hard to adjust the inputs such that it can get handled outside of the function, but it would be more convenient if it can get handled within the function.

///
@safe pure nothrow @nogc
unittest
{
    import mir.algorithm.iteration: equal;
    import mir.ndslice.allocation: mininitRcslice;

    static immutable a = [[3.0, 5, 2], [5.0, 2, 3], [2.0, 3, 1]];
    static immutable b = [[2.0, 3], [4.0, 3], [0.0, -5]];
    static immutable bt = [[2.0, 4, 0], [3.0, 3, -5]];
    static immutable c = [[26.0, 14], [18.0, 6], [16.0, 10]];

    auto X = mininitRcslice!double(3, 3);
    auto Y = mininitRcslice!double(3, 2);
    auto YT = mininitRcslice!double(2, 3);
    auto XY = mininitRcslice!double(3, 2);
    auto YTX = mininitRcslice!double(2, 3);
    auto YTX2 = mininitRcslice!double(2, 3);
    auto YTX3 = mininitRcslice!double(3, 2);
    auto result = mininitRcslice!double(3, 2);

    X[] = a;
    Y[] = b;
    YT[] = bt;
    result[] = c;

    symm(Side.Left, Uplo.Upper, 1.0, X.lightScope, Y.lightScope, 0.0, XY.lightScope);
    assert(XY.equal(result));
    symm(Side.Right, Uplo.Upper, 1.0, X.lightScope, YT.lightScope, 0.0, YTX.lightScope);
    assert(YTX.equal(result.transposed));
    //symm(Side.Right, Uplo.Upper, 1.0, X.lightScope, Y.transposed.lightScope, 0.0, YTX2.universal.lightScope); //error, the problem is that Y.transposed.lightScope._stride!1 not equal to 1, but YTX2.universal.lightScope._stride!1 is 1
    //assert(YTX2.equal(result.transposed));
    symm(Side.Left, Uplo.Upper, 1.0, X.lightScope, Y.transposed.lightScope.transposed, 0.0, YTX3.universal.lightScope);
    assert(YTX3.transposed.equal(result.transposed));
}

squeeze out more performance in case of no pointer aliasing

@9il

fortran can often be faster than C/C++ by assuming possibility of aliasing of memory pointers, allowing for better code generation, see for eg:
https://stackoverflow.com/questions/146159/is-fortran-easier-to-optimize-than-c-for-heavy-calculations/146186#146186

This has been proposed in D in https://issues.dlang.org/show_bug.cgi?id=10750 but not sure anything happened on this.

• maybe a lot of mir functionality could get a nice speed upgrade by implementing this feature. Is there any way to have a small experiment show what kind of speedup one could get (eg in a matrix vector operation)?

• That raises a question of how to let caller inform a function that the input pointers/slices have no aliasing.
  A runtime check would probably be possible and add negligible runtime cost?

relevant links

dlang/druntime#1891 templated array ops #1891
http://en.cppreference.com/w/c/language/restrict restrict type qualifier
https://forum.dlang.org/post/[email protected] C restrict keyword in D

In C, the restrict keyword implies that 2 or more pointer arguments in a function call do not point to the same data. This allows for some additional optimizations which were not possible before, finally making C as fast as Fortran.