armadillo, lapack, and intel’s MKL

I normally use ruby/gsl for everyday numerics because it’s fast to code and extend, and semantically clear, plus you can do cool things like previewing energy spectrum from within irb by interfacing with the gnuplot module—normally you’d write to a tmp file, switch to gnuplot console, and plot it there.

The problem with rb/gsl is speed. The other day, my boss walked in and compiled his fortran code on my machine. It beat my ruby code hands-down—one would think gsl, being a C library, should be on par with lapack, but apparently it’s not, and it’s not (entirely) ruby’s fault since I rewrote the same stuff in C, using gsl, and it’s still about 4 times slower than my boss’s fortran code using lapack. (I guess partly it’s b/c gsl is using its own blas implementation).

So I want something faster but still with natural semantics—e.g., matrix multiplication should be A*B, not dgremm(...A...B...)—so C++ seems a reasonable place to look at. So far I find armadillo suits my needs quite well. It is a c++ linear algebra library interfacing with lapack/blas.

On gentoo, this is what one needs:

1. If you have intel cpu, emerge sci-libs/mkl. This is a blas/lapack drop-in replacement from Intel. You need to go to intel’s website and register (free) for a non-commercial usage license. AMD has a similar library. Otherwise, just setup your blas/lapack of choice.
2. use eselect blas/cblas/lapack list/set to choose mkl as the blas/lapack implementation to use.
3. now emerge sci-libs/armadillo. It is important to install it after 1) and 2) b/c it will decide what library it’s linking against during compilation time

Now, #include <armadillo> in your cpp code, and use
g++ -O3 -larmadillo your_code.cpp -o your_exe
to compile. You don’t have to use -lblas -llapack as these are already taken care of by -larmadillo (which was done in 3 above, that’s why emerge order is important).

On a Mac OS X (my office workstation), the appropriate way to compile is instead:
g++ -O3 -framework Accelerate your_code.cpp -o your_exe
as per armadillo’s readme file.

I transcribed my ruby/gsl code into c++/armadillo, and on the Mac, it actually is 2 times faster than my boss’s fortran code—since both are using the same underlying blas/lapack implementation, I suppose there’s some unnecessary computation in the fortran code. At any rate, it seems safe to say the c++ overhead is not significant so I’ll happily settle for armadillo for the moment.

latex-beamer presentation on dual display (laptop + projector)

The latex-beamer class supports a \note{} macro where one can add notes/slide descriptions that can be hidden from the audience.Combined with the \setbeameroption{show notes on secondscreen} option (and the pgfpages package), each page in the resulting pdf file has the presentation slide and the notes slide placed side by side. Then one can set up a dual-display environment—laptop + projector being the scenario I’m interested in—so that the presentation slide will show up on the projector while the notes slide is on the laptop. The restrictions here are

1. the two displays better have the same resolution

   There is a way around this, described here, where essentially one sets up the projector to just reproduce part of the laptop screen, but I find the resulting image on the projector a bit too fuzzy.

2. The pdf viewer must be able to span the two displays in its presentation mode. Surprisingly my day-to-day choice of lightweight viewer, evince, doesn’t support this—instead it just spans a single display in its full screen mode. (I’m using xrandr for dual-display setup. more on that later). Luckily acroread behaves in the desired manner (with some caveat. see below)

Here’s the script I use to add a projector to the right of my laptop screen (i.e., right edge of laptop screen identified with left edge of the projector screen):

xrandr --output LVDS1 --mode 1024x768 --primary
# force use 1024x768 mode of the projector
xrandr --output VGA1 --mode 1024x768 --right-of LVDS1 || (xrandr --addmode VGA1 1024x768 && xrandr --output VGA1 --mode 1024x768 --right-of LVDS1)


Three things to note:

1. The reason why I put the projector on the right is because the window manager I use (awesome) automatically push all windows onto the left-most screen when a second screen is added, and you don’t want all your stuff to go up onto the projector–I’m sure there is a way to overcome this in awesome but I’m just too lazy.
2. The --primary is also necessary, this tells xrandr to set the laptop screen (LVDS1) as the primary one. Why? Because when going into full screen mode, acroread aligns the top-left corner of your document to the top-left of the primary screen. If your projector ended up becoming the primary screen, your notes will be displayed on the projector instead of your slides (which is pushed outside the visible range).
3. With the above layout, your beamer document should have notes frames placed on the left hand side, \setbeameroption{show notes on secondscreen=left}

For completeness, here is the script to shut off the projector output:

xrandr --output VGA1 --off
xrandr --output LVDS1 --auto