{"id":392,"date":"2015-12-22T15:00:06","date_gmt":"2015-12-22T15:00:06","guid":{"rendered":"http:\/\/drsfenner.org\/blog\/?p=392"},"modified":"2016-02-05T16:30:24","modified_gmt":"2016-02-05T16:30:24","slug":"into-the-weeds-ii-lapack-lapacke-and-two-paths-without-copies","status":"publish","type":"post","link":"http:\/\/drsfenner.org\/blog\/2015\/12\/into-the-weeds-ii-lapack-lapacke-and-two-paths-without-copies\/","title":{"rendered":"Into the Weeds II – LAPACK, LAPACKE, and Two Paths without Copies"},"content":{"rendered":"
\n
\n<\/div>\n
\n
\n

In the last post<\/a>, we tried to use lower-level LAPACK\/LAPACKE calls to remove some of the copying overhead of our operations. Well, it turns out that it didn’t work out so well (see the table at the end of the post). The fundamental reason why is that LAPACKE took the easy way out, when they decided to wrap LAPACK functions. In particular, whenever there is a C-\/Fortran-ordering issue (for a reminder<\/a>), LAPACKE simply makes a copy.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n<\/div>\n
\n
\n

Diatribe<\/h3>\n<\/div>\n<\/div>\n<\/div>\n
\n
\n<\/div>\n
\n
\n

Honestly, I can’t believe it. LAPACK is it<\/em>, when it comes to high-performance numerical libraries. And the "major, official" C-interface for LAPACK PUNTS<\/em> on performance and makes a copy? In the modern world, Fortran is more and more of a historical footnote (outside of numerical analysis), C is almost<\/em> a lingua franca<\/em> underneath many other programming systems, and data is more likely to live in row-major order ("natively"), and "FLOPS are free" (memory is the bottleneck in many cases) … well, I won’t go on. Point is, if we – as engineers – want to make use of LAPACK<\/em> proper and we live in C-land (which includes, at least, CPython), we have to make adjustments. Here, we’ll look at what those adjustments get us.<\/p>\n

BTW, we (in C-land) don’t have to clutch at LAPACK forever. There are other libraries out there — unfortunately, some of them are so wedded to LAPACK that they too, keep an emphasis on column-major data. Two that are more flexible, or at least allow for data in row- or column-major order to be used with high-performance numerical algorithms without copying<\/em>, are libFLAME<\/a> and FLENS<\/a>. Unfortunately, FLENS missed a great opportunity to move beyond the FORTRAN77 names (6 characters only) of raw BLAS and LAPACK. *sigh*<\/i> Someone should make a readable<\/em> interface around the FLENS library. One other, older project that looked interesting while I was researching these posts is Meschach<\/a> which is a pure C numerical linear algebra library.<\/p>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n<\/div>\n
\n
\n

One last comment: all hope is not lost for C-to-LAPACK. Here are some hints in the slow moving world of "building a better mousetrap" for numerical linear algebra. Two are from the GSL (GNU Scientific Library) mailing list and one from the LAPACK mailing list itself:<\/p>\n