[edit] I had a bug in my code; it does seem that the compiler is not picking up constants at compiletime. That is to say, it's not precomputing the final value at compiletime based on the value from those matrices. Here's how I modified the code to make sure: https://pastebin.com/iG21pTiP
Outperforming LAPACK with C++ metaprogramming
11–20 of 82 posts
Re: Outperforming LAPACK with C++ metaprogramming
#12> brute force Cramer's rule solution
This isn't really a fair comparison: trusty old DGESV will yield far more accurate results for badly conditioned problems since it does row swaps (partial pivoting). It might also rescale values; I don't remember the details. It would be much more reasonable to compare a hypothetical DGEC (double precision general matrix cramer's rule) routine.
Re: Outperforming LAPACK with C++ metaprogramming
#13I 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.
For numerical applications, one interesting project that comes to mind is the Terra programming language. It uses a flexible high level language (Lua) to metaprogram a fast and predictable C-like language (Terra). The advantage compared to the examples you mentioned is that each language can focus on its strength: the low level language being similar to C allows the programmer to better reason about performance and having a high level language for metaprogramming keep things simple.
There are also systems out there specifically designed for numeric applications that let you specify an algorithm in a high level DSL and generate highly performing C code, some of which might even tesr various versions of the code to find one that runs better on your machine (for example, the best way to iterate the data might be affected by cache sizes). I don't remember the names of these off the top of my head but the Terra PhD thesis has lots of references to them.
Re: Outperforming LAPACK with C++ metaprogramming
#14Please 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.
As an anecdote of just how powerful this can be, I once wrote a prototype of a simulation (written in C) that used a lot of integer divisions and needed to be run many times with different parameters. As a quick and dirty hack that took about half hour to implement, I decided to just have the program as a template string and the parameters be substituted in by a python script that called GCC. To the amazement of a ve…
Re: Outperforming LAPACK with C++ metaprogramming
#15I 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.
I was doing primarily research code at the time though, and the overall improvement in productivity more than made up for the fractional difference in run times for me. Of course, ymmv.
Re: Outperforming LAPACK with C++ metaprogramming
#16http://docs.mir.dlang.io/latest/index.html
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
Re: Outperforming LAPACK with C++ metaprogramming
#17It is somewhat unclear from his writing but did he compare this metaprogramming solution against OpenBlas or Atlas or just the reference BLAS/LAPACK implementation? If I was trying to do any significant linear algebra computations, I would definitely first try an optimized BLAS/LAPACK solution first.
Also, it seems the author solved a triangular system. LAPACK has special routines for that. Were they used? LAPACK is typically optimized for larger systems, not 5 unknowns. Also, 5 is not a great number for vectorized operations - it might even be beneficial to zero/one pad the matrix. Optimized LAPACK is often 5-10x faster than «basic LAPACK». BLAS/LAPACK was originally written in the 70s/80s and sometimes unroll l…
Re: Outperforming LAPACK with C++ metaprogramming
#18Earlier quoted context omitted.
As an anecdote of just how powerful this can be, I once wrote a prototype of a simulation (written in C) that used a lot of integer divisions and needed to be run many times with different parameters. As a quick and dirty hack that took about half hour to implement, I decided to just have the program as a template string and the parameters be substituted in by a python script that called GCC. To the amazement of a ve…
What made you choose a python script rather than C++ templates or the C preprocessor?
edit: oh nm, reread GP...
Re: Outperforming LAPACK with C++ metaprogramming
#19D's Mir does the same sort of thing, and metaprogramming in D is much nicer, because it was designed from the ground up instead of the bug elevated to feature that metaprogramming is in C++. http://docs.mir.dlang.io/latest/index.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
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.
Re: Outperforming LAPACK with C++ metaprogramming
#20I 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.