Use _aligned_malloc instead of posix_memalign on Windows

[tkelman]

This allows BLIS with the reference configuration to compile with MinGW (gcc 4.8.1 from mingw-builds, using MSYS2). The testsuite doesn't run successfully, it gets to the gemm tests then stops with an Error 127, see https://gist.github.com/tkelman/e1e619c2f1d2ff410068

If I manually change BLIS_SIMD_ALIGN_SIZE to 1 in bli_config.h, then a MinGW build does pass unit tests. From WinDbg, it looks like there might be an invalid use of _aligned_free with the default alignment of 16.

[fgvanzee]

Thanks for this patch, Tony. We have very few (zero?) Windows users/developers locally, so I'm glad someone out there is trying it out with Microsoft tools.

[tkelman]

So far I'm mostly interesting in using GNU tools on the Microsoft platform (among others), but MSVC might give me some better debugging info so we'll see.

I was very impressed by how quickly BLIS builds and how cleanly it's put together so far. Haven't benchmarked perf yet, but your recent papers look encouraging! If building shared libraries can happen soonish, I'm thinking of trying out plugging in BLIS into Julia as an alternate BLAS implementation.

[fgvanzee]

Tony, Thank you for your kind words regarding cleanliness. Hopefully you find performance to be satisfactory, but if it is not, keep in mind that we still do not have optimized kernels for many architectures, so low observed performance probably just means that the reference implementation is being called for the operation in question. And as you may have noticed, BLIS does not attempt to detect hardware flags (sse, avx, etc), nor does it attempt to adjust cache blocksizes based on the size of the L2/L3 caches---all of this must be done manually, for now. But, we would like to think that those are problems that have been solved elsewhere already, and that it will just take someone with the right expertise and motivation to come along and contribute those parts. Of course, if we wait long enough, this will rise to the top of my own queue. :)

Please keep in touch!

[jeffhammond]

+1 to Julia integration. That's a great target for BLIS.

On Saturday, June 14, 2014, Tony Kelman [email protected] wrote:

So far I'm mostly interesting in using GNU tools on the Microsoft platform
(among others), but MSVC might give me some better debugging info so we'll
see.

I was very impressed by how quickly BLIS builds and how cleanly it's put
together so far. Haven't benchmarked perf yet, but your recent papers look
encouraging! If building shared libraries can happen soonish, I'm thinking
of trying out plugging in BLIS into Julia as an alternate BLAS
implementation.

—
Reply to this email directly or view it on GitHub
#9 (comment).

Jeff Hammond
[email protected]
http://jeffhammond.github.io/

[fgvanzee]

Tony, as for integrating BLIS into Julia, we would be delighted if you were willing to take on such a project. It would also be interesting to see if the native (or even the object-based) BLIS interfaces would make it easier to include BLAS-like functionality within Julia.

[tkelman]

Hi @fgvanzee - I'd certainly be happy to experiment further, maybe starting on Linux first to make life a little easier. The big thing that's missing right now is building BLIS as a shared library. And the various architecture detection features as you said, but for a first experimental cut doing some things manually wouldn't be too bad.

Julia's build system is already set up to allow choosing between OpenBLAS and system BLAS (at build time), so adding another option should be feasible. There's some code in the Makefiles for Atlas too, but it might be bitrotting a little.

[fgvanzee]

I'll admit that I don't have much expertise with the issues involved with properly generating shared libraries. I did it for libflame once, but I'm not sure if I was employing best practices, etc. I'll add it to my to-do list and hopefully you can tweak or make suggestions as needed.