Benoît Jacob

Eigen2 as a vectorization library

2008-07-01T16:17:38Z

A big issue for any math-oriented software is vectorization i.e. how to make use of instruction sets such as SSE or AltiVec. Unfortunately this seems to be very hard for the compiler to do automatically, and even with Intel's own compiler, with complicated C++ code such as ours, the benefits were small (like +25% with ICC and +5% with GCC).

Yet, the theoretical benefit of vectorization is huge: with SSE, computations of floats can become 4x faster, and more in certain cases. So what math libraries tend to do, is to write their own explicitly vectorized paths for each architecture (SSE, AltiVec...) they support.

This is what Gael Guennebaud did a few monthes ago in Eigen2. We now have generic wrappers for vectorized operations: they abstract the underlying architecture and packet format, and are template in the numeric type. They got specialized by Gael for SSE2 and SSE3 and by Konstantinos Margaritis for AltiVec. Gael went on and made many parts of Eigen2 use these when applicable, so the end result is that Eigen can draw a large benefit form vectorization instructions when they are available (SSE or AltiVec), in a way that's completely transparent to the user, with graceful fallback to non-vectorized paths.

So we are now getting nice speedups like 4.7x for dot products of large vectors of floats, and 4x for the sum of coefficients of a vector. Gael also wrote a super optimized cache-friendly matrix product also taking full advantage of vectorization (3.5x for large matrices).

But what if Eigen2's vectorization could be used for more than just vector/matrix computations? Its expression templates allow it to be used even for very small computations without any overhead, which makes it an ideal candidate for being used as a generic vectorization framework. Calling 'Real' the type of the numbers we're dealing with, one can proceed as follows:

  enum { packetSize = Eigen::ei_packet_traits<Real>::size }; // number of reals in a Packet
  typedef Eigen::Matrix<Real, packetSize, 1> Packet; // wrap a Packet as a vector

And one can then use this Packet type to abstract the packets of the vectorization architecture. If there is no vectorization, a Packet will contain just one number.

So what I did was to start from here and do a little demo: a Mandelbrot Set viewer. It is up to 2.3x faster thanks to vectorization. It switches automatically between single and double precision. Normally that would have required one to write the vectorized paths twice for each architecture, but not so thanks to Eigen2, all that is abstracted.

If you're interested in checking it out:

svn co svn://anonsvn.kde.org/home/kde/branches/work/eigen2
mkdir eigen2-build
cd eigen2-build
cmake -DTEST_SSE2=ON -DBUILD_DEMOS=ON ../eigen2
make
demos/mandelbrot/mandelbrot

Some notes... it uses Qt's great threading framework to use as many threads as necessary to take advantage of your multi-core CPU; nevertheless the code is so small -- about 200 lines of code all in all, of which about 50 lines for the actual rendering -- that I am thinking that it could be a nice little plasma background-painter (or whatever plasma gurus call that!) for the KDE 4.2 timeframe! I for one would like my fractal wallpaper to come to life. Something's badly needed though: to make the rendering not block the user interaction. If you wish to help with that you're welcome! Another note: if you're serious about fractals be sure to check out Fraqtive! Of course the little toy program I'm presenting here is no match for Fraqtive.

Mandatory screenshot:

benchmarking virtual function calls in c++

2008-06-20T17:14:47Z

This is a followup to my two previous blog entries...

In order to measure the speed overhead of virtual function calls, I wrote a simple 3-float vector class with a dot-product method. One version is done without virtual functions, all in a single Vector class. The other version uses a pure virtual base class VectorBase implementing the dot product, and the vector coordinates accessors are virtual. Aside from that, there is no difference in the code.

The benchmark is here, and archive is here.

The results are impressive: the virtual version runs 3x slower than the no-virtual version.

Cool, now I'll have firm numbers to back up my design choices in Eigen :)

Simon, I hope that answers your request :)

Update:Gael found out that the big speed difference is in fact explained by the fact that the non-virtual function gets inlined. That also explains why more people get the same result with -O3 than with -O2. So that benchmark is not really measuring virtual function calls, instead it's more measuring the fact that virtual functions are less often inlined (and inlinable at all) than non-virtual functions, which is also a good reason not to use them in certain cases, like in the Eigen library for example where inlining of trivial functions is crucial.

virtual c++ classes and performance

2008-06-20T08:44:11Z

My previous blog entry started a debate on the overhead of virtual classes in c++.

First of all let's recall some facts, which I already recalled in my previous blog entry:

In most cases, the overhead of virtual classes in c++ is negligible. In most cases, there is no reason not to use virtual.

There. So if you're coding a GUI application or even many kinds of libraries, there is nothing to see here, move along and keep using the wonderful c++ feature that is virtual classes.

Now let's state the reasons why one might want in certain special cases to avoid 'virtual'.

1. It increases the "sizeof" of your class by the "sizeof" of a pointer, which is 4 or 8 bytes depending on your arch. In most cases you don't care. But if your classes have a small "sizeof" and you are going to create whole arrays of objects of it, then it suddenly becomes a big deal. In Eigen, the Vector2f (vector of two floats) has sizeof==8. If it were implemented as a virtual class, its sizeof becomes 12 (on x86 architecture) or even 16 (on x86_64). This means that an application storing large arrays of such vectors could see its memory usage double.

Note: I am not a c++ expert, so I checked before posting, and the sizeof of virtual classes indeed did increase by the sizeof of a pointer.

2. "Virtual inline" makes no sense, so if the compiler decides to inline a virtual function, it has to strip away its virtualness. There are circumstances under which it just can't allow itself to do that. If you rely heavily on inlining of trivial functions (like Eigen does) and are coding a library or template library (which is the case where inlining a virtual function might be problematic) then just be aware that sometimes the compiler won't inline your virtual functions.

3. (Updated several times -- will blog again to clarify) Even leaving aside inlining considerations, a virtual function call is slower because it requires first a lookup in the class's vtable; Here is a benchmark for that, here is an archive; I first believedthat it was showing the virtual version running more than 3x slower than the non-virtual version, but it turns out to just be that the non-virtual version gets inlined (which supports point 2 above). It seems hard and perhaps pointless to measure the raw cost of virtual calls.

4. Virtual function calls are indirect calls to locations computed at runtime. This may or may not cause trouble to the CPU's branch prediction mechanism. What I heard is that it used to, but modern CPUs don't have much trouble anymore with that. Anyway, this is very hard to quantify in a simple benchmark; if the issue exists at all on modern CPUs then it will probably show up only in involved examples.

Conclusion : There is absolutely no problem about "virtual" for non-computation-intensive code, like e.g. GUI code. In computation-intensive code, like e.g. in the back-end of an OpenGL application, things may be different.

That's all :)

C++ techniques: part 1: curiously recurring template pattern

2008-06-18T22:54:01Z

I've been thinking for a while that I should be blogging about some c++ metaprogramming techniques that I learned while coding Eigen:

1. the curiously recurring template pattern

2. "meta" versions of "if", "==", and other things

3. expression templates

Of course these techniques have been "known" for a long time, since they were discovered in the 90's. Some of them are already used in KDE; I saw some use of 1. in KHTML/KJS (edit: although not used for the same thing as discussed in this post), and 2 is quite commonplace anyway. Perhaps 3 is the least-known one, and the only one in which I'd have anything original to say.

Today let's talk about the curiously recurring template pattern.

Executive summary: this technique allows you, in certain cases, to get rid of "virtual" keywords, thus avoiding the overhead of a vtable and indirect function calls (edit: note that this is only one use of this technique, there are other uses which I don't discuss).

Let's look at the classical example below, which shows an abstract base class with a method to returning some data determined by the derived class -- something typically implemented using the "virtual" keyword.


#include <iostream>

class Animal
{
  protected:
    int age_in_years;

  public:
    Animal(int i) : age_in_years(i) {}
    virtual int actual_age() const = 0;
};

class Dog : public Animal
{
  public:
    Dog(int i) : Animal(i) {}
    virtual int actual_age() const
    {
      // one year is 7 dog-years
      return 7 * age_in_years;
    }
};

void msg(const Animal& a)
{
  std::cout << "This animal feels " << a.actual_age()
            << " years old." << std::endl;
}

int main(int, char*[])
{
  Dog d(3);
  msg(d);
  return 0;
}

The crucial point in the above program is that the msg() function takes an Animal, and the Animal class itself does not know how to compute actual_age(), so the virtual keyword tells the compiler to add complicated machinery (known as a vtable) to class Animal allowing to resolve the actual_age() call depending on the derived class. That machinery has a cost. Most C++ features, including OOP concepts, come at zero cost: that is the beauty of C++, something Stroustrup refers to as the "zero-overhead principle". This particular feature however (virtual functions), has a cost, so you don't want to pay it unless it's negligible. In many settings (like coding a GUI with Qt) this cost is negligible, but in other cases (like the above example) it is not.

Can you avoid paying that cost? The "virtual" keyword is in fact a very powerful tool, as the call to actual_age() is resolved at run-time. Sometimes you just need that: then there is no way to avoid using "virtual", and that cost is justified. Some other times however, you don't need that as the call to actual_age() can be resolved at compile-time.

Here enters the curiously recurring template pattern: it consists in using C++ templates to resolve the actual_age() call at compile-time. Here's how our program can be rewritten using that technique:


#include <iostream>

template<typename Derived>
class Animal
{
  protected:
    int age_in_years;

  public:
    Animal(int i) : age_in_years(i) {}
    int actual_age() const
    {
      return static_cast<const Derived*>(this)->_actual_age();
    }
};

class Dog : public Animal<Dog>
{
    friend class Animal<Dog>;
    int _actual_age() const
    {
      // one year is 7 dog-years
      return 7 * age_in_years;
    }

  public:
    Dog(int i) : Animal<Dog>(i) {}
};

template<typename Derived>
void msg(const Animal<Derived>& a)
{
  std::cout << "This animal feels " << a.actual_age()
            << " years old." << std::endl;
}

int main(int, char*[])
{
  Dog d(3);
  msg(d);
  return 0;
}

So the fun thing is that we have a circular "inheritance" (edit: note the quotation marks) diagram,


Dog ---> Animal<Dog> ---> Dog

and this is in fact perfectly legal c++, has been handled correctly by c++ compilers for a long time, and as I said, is already being used in KHTML/KJS, in Eigen, and probably in many places I never looked at.

Of course I'm not saying that virtual keywords should be replaced by that technique whenever possible: there are other considerations to balance. For example, this technique, making the base class a template taking the derived class as template parameter, will lead to duplication of the code of any function in the base class for every derived class calling it. So it may or may not be worth it... depending on the particular case it may be a life-saver (like it is in Eigen) or a very bad idea.

Update: as some nitpickers at reddit pointed out, there is a good Wikipedia page on this technique here.

c++ template libraries and debugging info size

2008-06-09T16:29:11Z

Dear Lazyweb,

Short version: do you know any way to limit the size of debugging info generated by g++ when compiling code that uses a c++ template library?

Long version: currently, with simple example programs using Eigen2 (a c++ pure template lib) the code generated by g++ at -g2 debugging level is 10x-30x bigger than the code generated at -g1 level, which itself is up to 1.3x-2x bigger than the code generated at -g0 level (no debugging).

The problem is that g++ -g2 emits line number and local variable info not only for the application, but also for the template library itself. Which is not really needed.

What would be cool would be to have g++ suddenly downgrade to -g1 when compiling code from the template library. So ideally, something like a set of #pragmas for controlling debugging levels, would be cool. Unfortunately that doesn't seem to exist. The closest thing that I have found, is the -femit-struct-debug-detailed option, which allows per-file tuning and in some case halves the executable size. However that still leaves the line number info and part of local variables info.

An overkill solution at least to the line-number-info problem would be to install preprocessed versions of our template lib's headers, removing as many linebreaks as possible. Of course that's not optimal, and that wouldn't remove the local variables info.

Any idea?

P.S. Eigen 2.0 is going to rock extremely hard now that Gael Guennebaud has been hugely contributing for monthes now, and Konstantinos Margaritis lent a helping hand. Some teasers -- explicit SSE2/SSE3/AltiVec vectorization ; compile-time intelligent determination of which temporaries to remove and of which loops to unroll ; the list goes on very very long. Gael is already heavily using Eigen 2 in his own 90,000 SLOC project, and I aim to make sure Avogadro can port to Eigen 2 in about one month. From KDE's point of view, this should be 4.2 stuff.

Eigen Mascot!

2008-04-09T08:16:26Z

A while ago I asked for proposals for Eigen's mascot owl. We got excellent proposals from 5 artists and exchanged many e-mails on Eigen's mailing list. Finally I uploaded the best pics from each artist and we voted. The vote occurred on the mailing list in order to ensure that mostly people with a true interest in Eigen, and who followed the discussions, participate. Other than that it was open to anyone. 9 people voted.

Note that the drawings below are 'only' sketches (!)

drumroll...dzing! The winner, and personally my favorite, is the "Silly Professor" in the top-right of this pic (Copyright 2008 David Benjamin, licensed under CC-BY-SA):

We'll be sure make use of the 'todo' and 'bugs' owl sketches. The 'engineer' is also very nice for a documentation section on internals.

The very close second (only 1 voice behind out of 9) is this one (Copyright 2008 Ronnie Tucker):

Again, you can see here the other candidates.

The extinction of standardization dinosaurs on the software planet

2008-04-02T06:45:43Z

According to this, the ISO are now calling a "standard" the Microsoft Office format (which is cynically called "Office Open XML"). I won't elaborate on the reasons why this thing is the opposite of what a standard should be, as this is clear to anybody not influenced by Microsoft.

What is interesting is that TeX, LaTeX, OGG/Vorbis, OGG/Theora, Perl, Python, PHP, Ruby, OCaml, are not standardized by any organization. Yet everybody knows that they are "self-standardized" by the free availability of extensive documentation and/or a by free-as-in-freedom unobfuscated reference implementation.

This shows that standardization organizations are no longer relevant in the software field. What really matters is free full documentation, free full implementation source code, and of course the absence of any patent risk. In other words, coming back to the fundamentals of what a standards is, what matters is evidence that any independent third-party can create and distribute a fully-conforming implementation. When this is the case, nobody needs an organization to certify that it is a standard.

That the ISO just proved itself open to the influence of special interests, is the consequence, not the cause, of its present irrelevance (again, in the software field). Since it is not needed anymore, nobody knows exactly what its mission is, what role it should play. Which allowed Microsoft to redefine that to its own advantage.

I think that the best move the ISO could now make is to acknowledge the limits of its own domain of application, which is the traditional industry, and to acknowledge that the software area is no longer such a traditional industry. In other words, ISO (and other standards organizations) should leave the whole software area, where they are not needed anymore.

Thinking further about this, here is perhaps the deep reason why in the end, software is beyond the field of application of standards organizations. This reason is that software is actually "just" mathematics. That was not obvious in the first decades of the computer industry, but it is becoming a concrete reality. Publishing the source code of a program is the equivalent of publishing the proof of a theorem. This is why the free software movement is changing the rules regarding standardization of software. In mathematics, once the proof of a theorem is published, there is no need for any authority to certify that the theorem is true. Everybody can independently look at the proof and realize that it is. And everybody can use the theorem without consulting its author. Likewise, once a free format specification is published with a free software implementation, there is no need for any authority (i.e. any standards organization) to certify that it can be used independently by any third-party (i.e. that it can be considered a standard). Thus, in the 21st century, a "standard" is just anything that has a full, free software implementation.

Eigen mascot owl: we need an artist!

2008-03-29T20:42:14Z

Today I'm looking for an artist who would be willing to draw Eigen's mascot. Eigen is a small but very powerful math library (linear algebra, i.e. matrices/vectors), and now's a good time for us to get a mascot as we are well on our way to releasing Eigen 2.0 in a few monthes, and are exceedingly proud of it :) Note that Eigen is getting more and more used in KDE (KGLLib, KTankBattle are two recent new users) and that the release of Eigen 2.0 will only accelerate that trend. It's also getting more and more users outside of KDE, some of whom have started contributing actively which is great.

The idea for our mascot would be an owl, and more specifically one "with ears" (i.e. a "duc"). I would like it to marry two aspects: it should be cute/cuddly, and it should still evocate the wisdom that owls are emblematic of (or at least an endearing and desperate attempt to look wise, from a little owl). A good approximation to what I have in mind is Archimedes, Merlin's pet owl in the Disney movie:

(see here for more). However, I would like it to be a bit more chubby/round and younger-looking. I would also like it to less serious. A good idea of the roundedness and of the attitude that I have in mind is found in the tux icons at TuxFactory, like this famous one:

However here I don't want the glassy aspect. I would like it with a lot of feathers and a fluffy aspect. Also note that in the above Tux icon, I like very much the silly eyes. I see very much our owl like that, and the attempt at wisdom could then be represented by a small wing raised like a teacher lecturing... or whatever idea you come up with.

In any case, if you'd like to contribute the Eigen mascot, please send your proposals to: eigen (at) lists tuxfamily org. It would be much appreciated! After we hopefully get a few proposals, we'll see which one is the most popular. Do not hesitate to write to us with only a sketch, so you can ensure early that people like what you're doing.

Tuxfamily

2008-03-18T14:12:36Z

This blog entry is plainly advertising for a little French nonprofit forge, TuxFamily. Well I hope it's OK to advertise them since they're working in their freetime and offer their services without charge. They do not even use ads to make money.

If you've been looking for hosting for your Free Software project, look no further, for this is the best forge that I know:

It itself is entirely Free Software

The server is damn fast. Check how Eigen's website loads fast.

It runs PHP4 and PHP5 so you can easily put a wiki online. They even have a tutorial (French wiki; apparently it's not yet translated). They also have other features like SQL server, download area for large files (up to a gigabyte or more)...

Not only the web server is fast, but SVN is also the fastest I've seen: "svn up" and "svn ci" take only a fraction of a second. They also support CVS... and Git !

Likewise, the mailing lists are the fastest and most reliable I've seen. I rely on tuxfamily for Eigen's mailing lists, and the mail is consistently delivered within a few seconds.

It does not use any ads. No ads on your project website, no ads on their website, no ads in the mailing lists...

The crew is awesome and very low-latency... all my requests have been handled within hours at most, and often within minutes.

That's what I've known for a long time and made me think of Tuxfamily as 'great'. But recently something made it move to my 'awesome' category. I'm a mathematician and my work consists partly in editing LaTeX files with colleagues. I've been looking for a forge to host collaborative math projects, i.e. doing math research in the same way as Free Software is done, just replacing C++ by LaTeX. SourceForge refused, but Tuxfamily accepted.

Lastly, Tuxfamily is running a donation campaign. It's their first one in 5 years of existence, and all the more justified since they don't use ads.

Eigen 2.0-alpha2; help wanted!

2008-01-07T11:05:21Z

Now that KDE 4.0.0 is tagged I guess it's OK to divert developers attention to KDE 4.1 stuff :)

So I just released Eigen 2.0-alpha2. Source tarball, Browse SVN.

Besides a ton of improvements over alpha1, the main novelty is that there is now quite complete API documentation.

New features since alpha1 include: ICC compiler support thanks to Gael Guennebaud, full enforcement of constness, support for row-major matrix storage (column-major remains default), and tons of API improvements and new methods.

Now's the time where you can really start using Eigen2 in your own project, if the current feature set is enough for you. I'm very happy with the architecture, and benchmarks show that it's very fast. According to sloccount there are 2,234 lines of code. Which is very, very little for what it does.

In fact, there are not so many expression-templates-enabled libraries out there:
- Blitz++ is of course great but is not a linear algebra library, so Eigen2 does not compete with it. Blitz++ is a general array library, and focuses on dynamic size while I want fixed size to be treated on an equal footing.
- TVMET only does fixed-size, does not allow expressions to be lvalues, etc., while having 5x more lines of code than Eigen2 (granted, it has some functionality not yet present in eigen2 such as applying a function to each coefficient). That said I have a huge respect for TVMET as it is by reading its source code that I learnt expression templates.
- Boost::uBLAS does not fully take advantage of expression templates. It treats them as a mere optimization that can be enabled/disabled at compilation. While expression templates are a great optimization, I believe that the most interesting thing about them is what they allow in terms of API design. Operating on the rows of a matrix should be as simple as

matrix.row(i) += factor * matrix.row(j);

This is what Eigen2 allows. This way one can write C++ code that really looks like pseudocode, and at the same time that's optimized. This is the real beauty of expression templates, and I regret that Boost::uBLAS doesn't take advantage of it. Another thing is that, like any BLAS, Boost::uBLAS only provides very basic functionality and one then needs to use another library for more functionality (such as inverting a matrix). By contrast, Eigen aims to be self-contained to cover all the usual needs of applications.

Update:I just found this: apparently fixed-size matrices and vectors are slow in uBLAS and for fixed-size they recommend to use TVMET instead! It's a small world.

I hope to have convinced you that by contributing to Eigen, you would be contributing to a very exciting project! For this is the motivation of this post: I need help!

While the Core module is quite complete, there are at least 6 more modules that we want to have for Eigen 2.0. I don't have time to write them all! So here is a TODO.

I would like very much to find volunteers quickly as the KDE 4.1 feature freeze is probably not too far away (though at least 3 monthes away) and if Eigen2 is good enough soon enough, it might be useful for several very exciting things in KDE 4.1, such as Step.

Then, a major user of Eigen2 will quite probably be KOffice 2.1, but this leaves us more time. Interestingly, the most advanced feature that KOffice/Krita requires, namely sparse matrix support, is also what Step requires. So, to any potential volunteer: by doing that, you will be a hero to both KOffice and KDE-Edu!

Eigen 2.0-alpha1

2007-12-18T10:04:48Z

Just a quick notice: I've released a first alpha of Eigen2; very preliminary website here (no documentation for now), source tarball here.

It's very far from being feature-complete. Only the Core module is there, while several others are planned.

That's all for now, I don't want to distract the KDE community too much from the upcoming 4.0 release :)

kde4 perfectly usable

2007-10-20T15:58:25Z

I am now running a full KDE4 session, from a svn checkout from yesterday. That's 10+ days after the tagging of beta3, and at the current pace of bugfixing, this means a lot of improvements.

So what's it like? Here's the obligatory screenshot. You can see Okular annotating a .djvu file (of course it also works with .pdf files) and Marble, which is a bit like Google Earth except that it can be embedded in any KDE4 app, which opens endless possibilities. You can also see the Battery plasmoid, which reacts instantly when you plug/unplug your laptop, and the Pager plasmoid, which works just as in KDE3. KWin defaulted to using OpenGL for compositing, and it works great here. Slamming the mouse to the top-right corner triggers the very useful Present Windows effect.

For me it's all perfectly usable, so I'm staying under KDE4 full-time. Not only to help with beta-testing (I already filed this bug report), but really because it already is stable and complete enough for me to use as my main desktop. I'm still using some KDE3 apps in my KDE4 session, but that's not a problem at all -- though of course it would be nice to use only KDE4 apps eventually.

On another note, Eigen2 development has been very fast recently, but more on this later -- for now the top priority for us all should be to help as we can to get 4.0 in shape, and Eigen2 will only be used in KDE 4.1 and KOffice 2.1. So I try to compensate for my current non-contribution to the 4.0 effort by doing some beta-testing, bug-reporting, and encouraging you all to do so :)

Eigen2 restart from scratch

2007-09-05T13:08:44Z

On saturday I decided that after all TVMET wasn't the appropriate starting point for Eigen2, so I restarted Eigen2 from scratch.

I started coding on Sunday, and today I made the initial commit to KDE's SVN in w /branches/work/eigen2.

I'm very happy about how things have been going since this restart. The basics are already there. Eigen2 already has matrices and vectors, both fixed-size and dynamic-size (reusing the CRTP trick from Eigen1), and of course expression templates (ETs). Non-square matrices are handled, and the ETs can be lvalues, not just rvalues.

The long road to Eigen 2

2007-08-26T07:52:04Z

It's funny how none of the existing libraries for vector and matrix math seems to do all what one might want. Each of these libs (Blitz++, MTL, LAPACK, GSL, TVMET, GMM++...) is specialized for certain needs. Usually, an app will choose the most suitable one for its needs, and be happy. But KDE is a huge meta-project with lots of sub-projects, so it has a very broad range of mathematical needs, which is not covered by any of the specialized libraries.

Writing from scratch such a general math library would take many man-years. However, what one can do is to merge existing libraries into a single one.

A killer feature that we absolutely want is expression templates. It's a strange C++ technique that allows to do things like a = b + c without paying the cost of having a temporary object allocated on the stack and then copied into a. Basically, it allows to use natural mathematical notation without any overhead. It even allows things like

matrix.row(i) += matrix.row(j)

which would be impossible otherwise.

The best expression templates for a matrix library are currently found in TVMET. Unfortunately, TVMET has been stagnant for 2 years and has been very little used by other projects, which is probably due to being too abstract, aiming too much for theoretical perfection.

For Eigen2, I decided to use TVMET as my starting point, instead of Eigen1. Of course, the contents of Eigen1 will be incorporated into Eigen2 as soon as possible. However, for now my work has been focused in shaping TVMET for my needs. I've converted it from autotools to CMake, and I've removed tons of stuff that I don't need, shrinking it down from 12000 to 7000 lines of code, and I've still room to shrink it further, and I've already added some good stuff from Eigen1, such as sane fuzzy comparisons. I'm currently porting the unit-tests from CPPUnit to QTestLib, and by the way I'm improving them a lot now that there are sane fuzzy comparisons.

What's next? Once I'll have fully reshaped TVMET and incorporated Eigen1 into it, I'll have a working Eigen2 for tiny (i.e. fixed-size) vectors and matrices. For dynamic-size objects, both dense and sparse, I'll wrap GMM++. In order to make this possible, the expression templates from TVMET will have to be adapted, as for instance loop unrolling will no longer be possible.

It's a very exciting project that is bound to fill a very bad gap in the current existing software. It requires only knowledge of pure C++, and vague notions of matrix mathematics. Your help is more than welcome, as there's a lot to do. So don't hesitate, join me: eigen at lists tuxfamily org.

[Kalzium] Icon status

2007-06-17T11:11:40Z

Carsten asks me to blog for him as PlanetKDE lost his blog:

Moin

Many new icons got in as well as some new features. Here you can see the new Short Table which is used a lot in (german) schools. As you can see some icons are missing and some need to be tweaked. But in general it already looks quite nice. All icons are rendered directly from SVG by the way!

Let me add that a new artist recently joined us and started contributing icons to Kalzium: Noémie Scherer. On the above picture, at least the icons for B, C, P, I are by her. She also draw icons for other elements that don't appear on this Short Table.

Update: Screenshot updated. Due to bad CMakelists some icons were not displayed. Also the image was scaled which was bad.

Drawing shadowed text inside an OpenGL scene

2007-05-08T18:32:07Z

I've been quiet lately, partly because I've had to spend most of my time on my thesis, and partly because I've done all my coding in Avogadro (no real website yet), which is not yet in KDE's SVN. If you read this story showing the new Kalzium3D features, maybe you'll be interested to know about libavogadro. This library initially took the kalzium3D rendering code but set much more ambitious goals, with currently 4-8 hackers including a promising SoC. There are immediate plans to port Kalzium to libavogadro; however libavogadro won't reach API stability in time for KDE 4.0 so we'll probably import a snapshot inside the Kalzium tree in the next days.

A new thing that libavogadro does is to draw labels on atoms. Rendering text inside an OpenGL scene is not straightforward. The problem is that in an opengl scene, you typically can't control the color of background. And if the text color is too close to the background color, then it's not readable. A bad workaround is to paint a semi-transparent dark rectangle behind the text. But in many occurences that feels ugly.

So a better solution is to draw a black shadow around the text. Just like the text below the icons on your KDE 3.5 desktop background. AFAIK, Qt does not yet provide that functionality, which is why KDesktop has its own code for that.

I initially tried to do it with QGLWidget::renderText, achieving the shadow by painting the text multiple times. Alas, renderText is not very fast, and multiple renderText calls are even slower. I got something working, but the framerate was divided by a factor of 5 (with Qt 4.2.3 and 4.3-b1). Too slow!

So I took my old TextRenderer class that I had written for Kalzium, and improved it to do shadowed text. This was achieved as follows: use a 16bpp GL_LUMINANCE_ALPHA texture, paint with Qt the character and read the luminance channel directly from the resulting bitmap; while the alpha channel is obtained by applying a trivial convolution filter (much like what KDesktop does, see above link). Characters are rendered on the fly whenever they are first needed, and are then cached and managed in a QHash.

The code is in avogadro's SVN tree at sourceforge but it's still very unclean and comments/docs are missing.

Obligatory screenshot (see how the shadow is necessary for readability on the white Hydrogen atoms):

This 35 frames-per-second is on my laptop with software-only rendering (mesa-swx11) and the highest level of detail. Disabling the labels on the atoms only increases the framerate by +10%, which is not too much if you consider how slow texture-mapping is on software-only systems.

Eigen 1.0

2006-12-30T20:21:41Z

Eigen 1.0 is released! This project started in July when we (that is, a handful of KDE developers) realized that we had a common need for some math functionality that no library out there seemed to cover reasonably. Sure, there are many linear algebra libraries, but they are either too small/amateurish, or too big/professional and focusing on heavy scientific stuff that we don't need. People objected (rightly) that adding a big dependency would be frowned upon by distro maintainers. So we decided to start our own linear algebra library, Eigen.

5 monthes later, it's there. If you're looking for a lightweight library for vectors, matrices and related math stuff, please give it a try. We have fixedsize classes, as in "float v[SIZE];" and they're very fast and specially optimized for low sizes (<=4). We also have dynamic-size classes, which can be useful if you're developing e.g. a spreadsheet and want to be able to solve any system of arbitrarily many linear equations. And we have special classes for projective geometry, which can be useful in OpenGL apps, as was demonstrated in my previous entry.

By the way, and Eigen is very fast with GCC, whereas some other linear algebra libraries will tell you to use the intel compiler instead. The issue here is that GCC has problems with loop unrolling. In particular, GCC often fails to unroll nested for loops, which is annoying e.g. for matrix product, see this bug report. In Eigen, this problem is worked around by manually unrolling loops in fixed-sizes up to 4 (which are the cases where loop unrolling is wanted).

Eigen example: the OpenGL camera problem

2006-12-29T15:43:16Z

It looks like Eigen 1.0 will be out in 2006 as promised. For this occasion, I have fixed a small example program. Since the beginning, one of the primary goals of Eigen has been to provide the math functionality that is useful in OpenGL apps. And one of the most common problems when writing OpenGL apps is, how to let the user freely move the camera around? Representing the camera orientation by 3 angles just doesn't work, and leads to the gimbal lock problem. So the best solution is to represent the camera position and orientation by a 4x4 matrix and pass it directly to OpenGL. The question is then, how to generate this matrix from the user input? This is where Eigen comes into play. Here is the GLWidget::mouseMoveEvent() function from the Eigen example program:

void GLWidget::mouseMoveEvent( QMouseEvent *event )
{
    QPoint delta = event->pos() - m_lastPos;
    m_lastPos = event->pos();
    if( event->buttons() & Qt::LeftButton )
    {
        m_cameraMatrix.prerotate3( - delta.x() * ROTATION_SPEED, AXIS_Y );
        m_cameraMatrix.prerotate3( - delta.y() * ROTATION_SPEED, AXIS_X );
    }
    if( event->buttons() & Qt::RightButton )
    {
        m_cameraMatrix.prerotate3( - delta.x() * ROTATION_SPEED, AXIS_Z );
        m_cameraMatrix.pretranslate( delta.y() * TRANSLATION_SPEED * AXIS_Z );
    }
    if( event->buttons() & ( Qt::LeftButton | Qt::RightButton ) )
        update();
}

This lets the user rotate around by drag & drop with the left mouse button, and tilt and move forwards/backwards by drag & drop with the right mouse button. Then the paintGL function looks like

void GLWidget::paintGL()
{
    glLoadMatrixd( m_cameraMatrix.array() );
    drawScene();
}

Obligatory screenshot:

Bruce Perens's open letter to Novell's CEO

2006-11-22T21:59:38Z

Bruce Perens has just posted this petition:

Protest the Microsoft-Novell Patent Agreement

First benefits of using Eigen for Kalzium

2006-11-17T09:23:14Z

In Kalzium's 3D viewer, a problem was that when you loaded a molecule, the default viewpoint was not always optimal, sometimes totally unreadable. For instance, look at this molecule of L-tryptophan :

Of course, Kalzium always allowed to freely rotate around the molecule, so after some mouse effort, you could get that:

But then, a second problem appears: depending on the viewing angle, double bonds can look like single bonds. In the above pic, one should see 6 double bonds. This even mislead some people into believing that our molecule files were wrong! So I sat down and figured that the first thing to do was to perform a linear regression to compute the best-fitting plane for the molecule. Once we know that plane, elementary geometry allows to find a nice viewpoint and to orient the multiple bonds in a convenient way. So I implemented linear regression and a computeFittingHyperplane function in Eigen, and reworked Kalzium's 3D viewer to make use of it. Result:

I haven't had to do any manual rotation for this screenshot, this is the exact viewpoint you get when you load the molecule. Also note that now the 6 double bonds clearly appear. Maximizing the window, I got this.

About speed: for these screenies, I take the high-quality mode, and get 56 FPS on my software-only (no hardware acceleration) 1.66 GHz Intel Core 1. In low-quality mode, I get 178 FPS, and at this window size, the visual difference is not too big. Even on Carsten's laptop, it runs OK ;)

Update: as a comment pointed out, the molecule file is wrong, there is one hydrogen atom missing and one double bond too much. This was a bug in the (very old) molecule file that I used, and has been fixed since in the BlueObelisk project.

Some lines by Levinas that apply to Software

2006-11-16T09:16:49Z

Here's a rough translation of a few lines from Levinas's 1934 essay, Quelques reflexions sur la philosophie de l'hitlerisme (3 paragraphs to the end) :

An idea, by propagating, detaches from its starting point. It becomes, despite the unique accent given by its creator, a common good. It is anonymous. The one who accepts it becomes its master as much as the one who proposed it. Thus, the propagation of an idea creates a community of "masters" -- it is an equalization process. To convert, or to convince, is to create oneself peers. The universality of an order in the occidental society always reflects this universality of truth.

But force is characterized by another kind of propagation. The one who exercises it doesn't detach from it. Force doesn't dilute into those who are subjected to it. It remains attached to the personality or society who exercises it, widening them while subjecting the rest to them.

Now replace "idea" by "Free Software" and "force" by "Non-Free Software".

Update: improve translation, replace "strength" with "force".

Eigen 0.9.3, new website, mailing list

2006-11-15T11:18:45Z

Eigen 0.9.3 was released today with important compilation fixes. Because Eigen is templates, compilation problems are difficult to detect, so before the next release I'll add unit-tests specifically for that.

The new permanent website of Eigen is here:

http://eigen.tuxfamily.org

Also we got a mailing list: eigen at lists tuxfamily org. To subscribe, send a mail with subject "subscribe" to eigen-request at lists tuxfamily org.

Eigen 0.9.2

2006-11-12T19:06:46Z

Eigen 0.9.2 is here. Lots of sparse improvements since 0.9.1, plus one "big" feature: functions for linear regression analysis. I've been careful to write hopefully good documentation for that. By the way, did you know that doxygen allows to use LaTeX to produce png's of math formulas?

Eigen got a new website, entirely doxygen-generated. Because it's doxygen-generated, it would probably not be a good idea to host it in KDE's SVN, so I'm registering a project at TuxFamily. But there really are some good sides with using doxygen to create a website. For instance, the LateX png feature provides a cool way to show e-mail addresses while protecting them from spam!

On the cool side, it seems that one big scientific (non-mathematical) Free software project is considering moving to Eigen ! I'll handle the porting soon and will let you know once it's official :)

Havoc Pennington on the Novell/MS agreement

2006-11-08T10:26:31Z

I'd like to draw your attention on this blog post, which I found interesting:

http://log.ometer.com/2006-11.html#7

In particular, he argues that the Novell FAQ "tries to weasel out the spirit of the GPL". I tend to agree with him, but I don't have the necessary knowledge to have strong opinions on this issue.

Eigen : let your apps do the math !

2006-10-21T16:56:19Z

Eigen 0.9.1 has been released today. It's a lightweight C++ template library for linear algebra: vectors, matrices, solving systems of equations...

Eigen provides:
* classes for vectors and matrices, in two versions: fixed-size and dynamic-size. The fixed-size classes are zero-overhead and never cause dynamic memory allocations. The dynamic-size classes provide better flexibility. Both versions use the same C++ code, thanks to a C++ trick known as the Curiously Recurring Template Pattern.
* classes for easy solving or systems of linear equations. Again, both fixed-size and dynamic-size versions are provided.
* classes for directly handling LU decompositions.

Kalzium has already been ported to Eigen, which will allow for more 3D coolness in the molecule viewer. A handful of other KDE apps are also considering using it. But, as Eigen is pure C++ with no dependency at all, it could very well be used by non-KDE apps, which is why we put it in trunk/kdesupport.

We plan on a 1.0 release within one month. To all app developers with a need for some math functionality : now's the time to give Eigen a try!

Website: http://edu.kde.org/kalzium/eigen/index.php
API documentation: http://www.math.jussieu.fr/~jacob/eigen/dox/
Source code: http://websvn.kde.org/trunk/kdesupport/eigen/
IRC: #eigen on freenode

Digg this entry