in C++17 you can get generic loop unrolling templates in 8 lines of code:
https://godbolt.org/g/2Di4PM
Outperforming LAPACK with C++ metaprogramming
41–50 of 82 posts
Re: Outperforming LAPACK with C++ metaprogramming
#42Modern Fortran (especially upcoming Fortran 2018 standard) is good enough already for those kind of libraries. Moreover, big chunks of the computations are implemented in assembly in BLAS/LAPACK. What surprises me, that authors of those libraries still stuck in Fortran 90.
Re: Outperforming LAPACK with C++ metaprogramming
#43This article makes no sense at all. It compares a numerically unstable O(n!) algorithm (Cramer's rule) to a numerically stable O(n^3) algorithm (Gaussian elimination).
Re: Outperforming LAPACK with C++ metaprogramming
#44Earlier quoted context omitted.
> relying on raw string concatenation > it's not so bad You can always use the C preprocessor in C++ if raw string manipulation is enough. Seriously, though, constexpr means C++ also has static if, compile time loops, function eval, etc.
> C++ also has static if Not even close. You can't conditionally insert a member.
Hopefully that will be fixed in a future C++ standard. There is an interesting static reflection proposal floating around that would allow for this, plus more.
Re: Outperforming LAPACK with C++ metaprogramming
#45For those wondering the lapack guys are working on a new version of lapack to run on heterogeneous architecture including gpus. See their work at http://www.icl.utk.edu/research I have worked with these guys and all I can say is good luck outperforming the highly optimized routines they have written. My bet is that the the guy writing this blog used a non optimized version of lapack.
There's no mystery here, author is only solving a 5x5 system. LAPACK will have barely finished checking function call parameters by the time a fully specialized and inlined solver is finished. Also, from a cursory inspection, author does no pivoting [edit: worse, it just uses Cramer's rule, which is insane], so their solver will be much less numerically robust (but this is admittedly less of a problem for the 5x5 cas…
Cramer's rule is unstable even for 2x2 problems
Re: Outperforming LAPACK with C++ metaprogramming
#46Please check with array initialized from file or other dynamic source. With maximal inlining, there's a risk of constant propagation resulting in a lot of computation happening at compile time rather than run time.
> With maximal inlining, there's a risk of constant propagation resulting in a lot of computation happening at compile time rather than run time.
Without even reading TFA, this was my first thought, remembering back to implementing Fibonnaci's sequence in template metaprogramming from "Thinking in C++, Volume 2": http://web.mit.edu/merolish/ticpp/TicV2.html#_Toc53985733
It's cool and useful to be sure, but as costrouc pointed out, LAPACK has been optimized for a very long time by some very smart people. Most people who have not studied the field for a bit are unlikely to come across a more optimal method.
Re: Outperforming LAPACK with C++ metaprogramming
#47I wonder if the similar tricks work in other languages with similarily optimizing compilers, but "nicer" metaprogramming, such as Common LISP, Rust and perhaps OCaml? (with camlp4) Even more interesting would be whether this leads to the same huge performance gains in those languages as well.
Just be wary of performance gains claims. Per other comments this implementation is highly optimized for a specific use and uses a numerically unstable algorithm.
Re: Outperforming LAPACK with C++ metaprogramming
#48Please check with array initialized from file or other dynamic source. With maximal inlining, there's a risk of constant propagation resulting in a lot of computation happening at compile time rather than run time.
Poking at the various compilers the machine instructions generated from the article appear to produce an unrolled version of the operation (as claimed by the article):
https://godbolt.org/g/Wmj8ar
Re: Outperforming LAPACK with C++ metaprogramming
#49Earlier quoted context omitted.
There's no mystery here, author is only solving a 5x5 system. LAPACK will have barely finished checking function call parameters by the time a fully specialized and inlined solver is finished. Also, from a cursory inspection, author does no pivoting [edit: worse, it just uses Cramer's rule, which is insane], so their solver will be much less numerically robust (but this is admittedly less of a problem for the 5x5 cas…
Cramer's rule is unstable even for 2x2 problems
I think gp is missing a “less” before “numerically robust”
Re: Outperforming LAPACK with C++ metaprogramming
#50Earlier quoted context omitted.
> instead of the bug elevated to feature that metaprogramming is in C++. That inflammatory wording doesn’t add anything to your comment. If you wanted to compare D with C++ it’d be a lot more useful to link to something which does that rather than just the documentation index.
C++ metaprogramming was an accident. Expression templates are a huge, obscure, and very surprising hack. I don't know about you, but I find them really hard to understand. SFINAE wasn't meant to be used for compile-time branching, but when people realised that it could be used that way, it was just about the only tool for metaprogramming in C++. It certainly wasn't designed for that purpose, though. C++ has for a lon…
Again, I'm not defending C++ or disparaging D but saying that this style of abrasive advocacy doesn't leave the reader knowing anything more about D than they already knew. Your last sentence is a great example:
> My second link does that, compares Mir to a bunch of other numeric libraries, most in C++.
This is technically correct but not helpful because it just shows a bunch of benchmark results. If the point is to demonstrate how D is more powerful for this kind of programming what would be useful is something which shows the same function written in modern C++ and D so you could see how they differ.