Phoronix and “benchmarks”

Gotta love Michael Larabel / Phoronix sometimes. One of the latest posts is particularly amusing; He uses three graphs to show us what could have been summed up in a sentence: LLVM trunk’s optimization of LLVMpipe is pretty much unchanged from LLVM 3.0.


Cairo 1.12.0 – buggy as buggery?

Cairo 1.12.0 has been released with a swag-full of new features (such as XCB backend) and improvements. Apparently. For me, it causes random text corruption, noticeable most prominently in Firefox (when built with –enable-system-cairo of course) but also in a few other GTK-based apps. I’ve tried compiling with both GCC 4.7.0, 4.6.3 and LLVM 3.0 without any resolution. Cairo 1.10.2 doesn’t produce corruption, 1.12.0 does. For the moment I recommend holding off on the upgrade.

The situation would be a lot better if Cairo had a halfway decent test suite. It does have a test suite, but when I run it (on 1.12.0 or 1.10.2) I get a huge number of failures which are completely inexplicable to me and apparently to LFS authors also. Quotes from that page:

As the test suite is currently unreliable, it is best to simply skip it at this time.


Note that the tests take a long time to run and many of them fail for unknown reasons.

… which pretty much sums up my experience as well. What a joke.

Update: seems I’m not the only one who’s seen this. Not clear at this stage whether it’s really a bug in cairo, in the radeon driver, or the EXA extension.

Cinnamon. WTF is it?

Check out the Cinnamon web site.

It’s not so bad, as web sites go, in terms of appearance. Nice width, good text/background contrast. They’re probably using WordPress in the backend. That transition between screenshots (if that’s what they are) effect is really nice, I like it.

Notice they had a release recently – up to version 1.4 now, it seems, and 1.3.1 was … well, I don’t know how long ago, because the news items aren’t dated, which does seem like a serious omission, but at least I can click the links to get the full story with date: 1.4 was released 14/3/2012 and 1.3.1 was 20/2/2012, less than a month earlier. Ok, I can live with that. Hmm, fast release schedule! Usually a sign of a project in its infancy: enthusiastic developers, and plenty of low-hanging fruit in terms of bugs to fix and features to add. Which makes the next observation even more puzzling.

No – mention – anywhere – of – what – the – heck – it – is.

How exactly do you manage to put together a website with flashy screenshots and monthly news items and still neglect this most basic, this most essential of details? I can only assume that the webmaster is some form of greater ape. Possibly an orangutang. Don’t get me wrong, I like orangutangs, they have an odd graceful sobriety about them, and you can train them to wash clothes and (apparently) bang up a quick website, but they just don’t have the intelligence of a real human.

So please, Cinnamon, ditch the ape, get a human, and put an “about” page on your crappy website.

(For anyone who’s just itching to know, LWN has an entry here which explains what Cinnamon is).

Updated C compiler benchmarks, Feb 2012

With several new compiler releases it’s time to update my compiler benchmark results (last round of results here, description of the benchmark programs here). Note that the tests were on a different machine this time and the number of iterations was tweaked so numerical results aren’t comparable.

Without further ado:

So, what’s interesting in this set of results? Generally, note that LLVM and GCC now substantially compete for dominance. Notably, GCC canes LLVM in bm4, where it appears that GCC generates very good “memmove” code, whereas LLVM generates much more concise but apparently also much slower code; also in bm8 (trivial loop removal – though neither compiler actually performs this optimization, GCC apparently generates faster code). On the other hand LLVM beats GCC quite handily in bm6 (a common subexpression elimination problem).

GCC 4.6.2 improves quite a bit over 4.5.2 in bm5 (essentially a common subexpression refactoring test). However, it’s slightly worse in bm3 and for some reason there is a huge drop in performance for the bm7 test (stack placement of returned structure).

The Firm suite, surprisingly, mostly loses ground with 1.20.0 and remains uncompetitive.

Edit 25/03/12: I’ve noticed a flaw in bm6, which when corrected causes GCC to perform much worse – about 0.5 seconds rather than the 0.288 reported above.

Evince installation documentation

I just upgraded Evince on my system. Initial attempts were unsuccessful; I got the following message when trying to start it:

(evince:22841): GLib-GIO-CRITICAL **: Settings schema ‘org.gnome.Evince.Default’ is not installed

I have no idea what this means so in the interim I try upgrading ‘glib’. This mostly goes without hiccups (except that newer versions of glib apparently have a dependency on libffi, for reasons which are tentatively explained in the glib README), however, I get the same error message when I try to start Evince. After some Googling, I discover the necessity of ‘compiling the schemas’:

# glib-compile-schemas /usr/share/glib-2.0/schemas

No mention at all of this in Evince build documentation. It looks like the schema might be compiled automatically if you “make install” Evince without setting DESTDIR, but frankly the necessity of compiling the schema should be documented.

Crappy g++ documentation on template instantiation

The g++ documentation says on template instantiation:

G++ has extended the template instantiation syntax given in the ISO standard to allow forward declaration of explicit instantiations (with extern), instantiation of the compiler support data for a template class (i.e. the vtable) without instantiating any of its members (with inline), and instantiation of only the static data members of a template class, without the support data or member functions (with (static):

extern template int max (int, int);
inline template class Foo<int>;
static template class Foo<int>;

The one I’m interested in is “extern”. The docs as quoted above say that it “allows forward declaration of explicit instantiations”, but that’s useless; explicit template instantiations don’t need forward declarations, you may as well just do the instantiation. Of course, the documentation is actually incorrect by omission: the “extern” keyword in front of an explicit template instantiation (as in the example above) actually causes gcc not to emit the instantiated template (even when it would otherwise do so because of implicit instantiation). This means that we can use this syntax to avoid emitting a template instantiation which we know is already emitted in another module.

Avoiding the emission of a template instantiation in many cases has only limited practical value – it might reduce compilation and linkage time ever so slightly, and likewise reduce the disk space used by object files ever so slightly. It would also allow for removing the emitted instantiation from a shared library or executable if the same instantiation was known to be present in another library that we were linking against.

The point is, there’s a potentially useful feature which isn’t documented, yet the syntax is documented – with an incorrect description of what it does.

MySql 5.1 build documentation – utter crap

I’m currently experiencing the joy of upgrading from MySql 5.0 to 5.1 on our server. After building MySql with the same “configure” options as used previously, then installing it, I run the “mysql_upgrade” command, which gives me some alarming output, basically along the lines of:

Error : Unknown table engine 'InnoDB'
error : Corrupt
Error : Unknown table engine 'InnoDB'
error : Corrupt
Error : Unknown table engine 'InnoDB'
error : Corrupt

Unknown table engine? what the… Corrupt?

So, I go do some googling and reading of manuals (which I suppose I should have done beforehand, sure) and it turns out that in 5.1, the “InnoDB” storage engine (the only one worth actually using, as it actually supports locking and transactions) is now a “plugin” and you need a configuration option to enable it:


Ok, so, problem solved, right? Wrong. I then get the following output in the mysqld log:

111212 14:27:37 [ERROR] Can’t open shared library ‘/u1/overflow/usr/local/mysql-5.1.60/lib/mysql/plugin/’ (errno: 2 mysqld: fatal: relocation error: file /u1/overflow/usr/local/mysql-5.1.60/lib/mysql/plugin/ symbol )
111212 14:27:37 [ERROR] Couldn’t load plugin named ‘innodb’ with soname ‘’.

Hmm, not what I call an extremely useful error message. There seems to be some symbol resolution problem, but I don’t even know what particular symbol it’s having trouble with. Rather than mess around and trying to debug this, I go back to the build options. When I run “configure –help” I see, amongst other things:

  --with-plugin-PLUGIN    Forces the named plugin to be linked into mysqld

Err, what the… so, if say “–with-plugin-innodb” or something similar, it will link the plugin statically into mysqld? Weird. But hey, it’s a worth a shot. I try adding that to my “configure” options, and it immediately spews out a message saying that it doesn’t recognize the “–with-plugin-innodb” option! What the hell? I try a few variations but no joy. Getting quite frustrated by now. Ok, the “configure –help” output doesn’t match what “configure” actually accepts, maybe the manual will be more update? Hmm, not really; it’s a bit of a confusing mess actually, and it claims that “–with-plugin-PLUGIN” should work. It does suggest however that no plugins are built by default, and therefore I decide to try the alternative “–with-plugins=innodb_plugin,innobase”. I’m not really sure if I need “innobase” but it seems like it can’t hurt. Waiting for compilation to finish now…


So, compiling without InnoDB support still produced a file called “”, which I can’t actually use? What the?