The lone C++ coder's blog

I had another of these annoying mixed-mode DOS/Unix text files that suffered from being edited in text editors that didn't agree which line ending mode they should use. Unfortunately Emacs defaults to Unix text mode in this case so I had an already ugly file that wasn't exactly prettified by random ^M characters all over the place.

I also don't have the cygwin tools on the machine that I was seeing this problem on, I couldn't just run unix2dos or dos2unix over the file and be done with it, but at least I had emacs on that machine. So, emacs to the rescue again...

First, I used query-replace to get rid of the ^Ms in so the file was turned into a "proper" Unix text file. The trick here is that you need to use control-Q to quote the control character. In my case on a Windows box, the key sequence was M-Shift-% Control-Q Control-M and then use the empty string as a replacement value. Job done, we've now got a proper Unix mode text file. Well, after almost wearing out the 'Y' key but of course you can use replace-string instead.

In order to turn the Unix mode text file into a Dos mode one, run the command set-buffer-file-coding-system with the parameter undecided-dos and save the resulting file. Job done.

Unfortunately the excitement from seeing OpenSolaris's disk performance died down pretty quickly when I noticed that putting some decent load on the network interface resulted in the network card locking up after a little while. I guess that's what I get for using the on-board Realtek instead of opening the wallet a little further and buy an Intel PCI-E network card. That said, the lock-up was specific to OpenSolaris - neither Ubuntu nor FreeBSD exhibited this sort of behaviour. I could get OpenSolaris to lock up the network interface reproduceably while rsyncing from my old server.

This gave me the opportunity to try the third option I was considering, Ubuntu server. Again, this is the latest release with the latest kernel update installed. The four 1TB drives were configured as a RAID5 array using mdadm. Once the array had been rebuilt, I ran the same iozone test on it (basically just iozone -a with Excel-compatible output). To my surprise this was even slower than FreeBSD/zfs even thought the rsync felt faster. Odd that.

Here a few pretty graphs that show the results of the iozone write test - reading data was faster, as expected, but the critical bit for me is writing as the server does host all the backups for the various other PCs around here and also gets to serve rather large files.

First, we have OpenSolaris's write performance

FreeBSD with zfs is noticeably slower, but still an improvement over my existing server - that one only has two drives in a mirrored configuration and oddly enough its write speed is about half of the one on the new server:

FreeBSD with the geom-based raid is slower but I believe that this is due to the smaller number of disks. With this implementation you need to use an odd number of disks so the fourth disk wasn't doing anything during those tests. Not surprising that the overall transfer rate came in at roughly 3/4 of the zfs one.

Ubuntu with an mdadm raid array unfortunately brings up the rear. I was really surprised by this as it comes in below the performance of the 3 disk array under FreeBSD:

One thing I noticed is that while the four Samsung drives are SATA-300 drives, the disk I reused as a system drive is not. I'm not sure if that does make any difference but I'll try to source a SATA-300 disk for use as the system disk to check if that makes any difference at all. I'm also not sure if FreeBSD and Linux automatically use the drives command queueing ability. On these comparatively slow but large drives that can make a massive difference. Other than that I'm a little stumped; I'm considering the purchase of the aforementioned Intel network card as that would hopefully allow me to run OpenSolaris but other than that I'm open to suggestions.

The good news is that the hardware seems to be behaving it for a while now and everything appears to Just Work. FreeBSD makes things easy for me in this case as I'm very familiar with it so I only spent a few hours pretty much getting everything set up. So far, so good.

I've rsynced most of the data off the old server and while doing that I already had this nagging feeling that the transfer seemed to be well, a little slow. Yes, I transferred several hundred Gigabytes but nevertheless I thought it would take less time, so this morning I did a few performance tests using Samba 3.3 on the new server. Turns out the performance was around 12-25 MB/s and that's a lot less than I expected. In fact, that's a little too close to 100Mb network performance for me liking - even without using jumbo frames I would think that a straight data transfer would be faster than this. Unfortunately I had introduced a few unknowns into the equation, including using the FreeBSD implementation of zfs. I am not saying that it is the culprit but I'll start with server disk performance measurements before I do anything else.

Ah well, looks like the old server needs to do its job a little longer then.

Update: Running iozone on the machine itself suggests that the write speed of 12MB/s-13MB/s I was seeing via Samba are more or less the actual transfer rate to disk on the zfs software raid array. I'm not sure if that's a limitation on my hardware or a problem with the (still experimental) zfs implementation on FreeBSD. Nevertheless this is a little on the slow side to put it mildly (the four disks should easily saturate a gigabit network link) so I guess it's time to wipe the zfs config and use FreeBSD's native RAID5 instead for a check if that hypothesis is holding water. If it's not then the bottleneck is somewhere else.

Update II:FreeBSD's graid3 unfortunately needs an odd number of drives which left one of the 4 Samsung idle. Same tests suggest that the performance was 1/4 less than FreeBSD zfs with four disks so it seems that it was driving it as fast as it can. Hmm. Just to get a comparable figure I threw OpenSolaris on the box, again with the four 1TB drives as a single zfs tank with a single directory structure on it. With the default settings, the same iozone tests are nudging write speeds over 35MB/s. Not as fast as I expected by a long shot but noticeably better at the expense of a more painful configuration. Something to think about but I think I need to test a few other configurations before I can really make up my mind as to which way I want to go.

Up to now I've mostly been using recycled workstations as my home mail, SVN and storage server. Nothing really wrong with that as most workstations are fast enough but I'm running into diskspace issues again after I started backing up all the important machines onto my server. That's especially annoying as I started using Time Machine on my iMac and now haven't got enough space left on the server to also back up the MacBook. Time Machine is great as a backup solution simply because it is so unobtrusive and it appears to just work.

Inspired by an article in the German magazine c't, I decided that instead of finding another used desktop machine to recycle, I was going to build a proper home server with a few additional bells and whistles. I'm still using mostly desktop parts as I can't really justify the expense and noise of "proper" server components but I tried to select decent quality parts. Here's the hardware list:

I'm currently in the final stages of converting a library from using raw pointers to using boost::shared_ptr. This is mainly done to resolve issues with pointer ownership rather than the outright prevention of memory leaks, but the latter is a nice side effect of the former.

The one problem that I ran into during this work was that the library and its clients make rather heavy use of polymorphism. Of course in 99% of the code that was fine as the objects were accessed through pointers to base classes, but the last 1% was causing problems because that part of the code contained lots of dynamic_cast statements. As these classes unfortunately needed to know the exact type they were dealing with, there was no easy way around the use of these idioms, either. It probably isn't news to most of the people reading this blog that dynamic_cast and boost::shared_ptr don't play that nicely but I stepped right into that.

The main issue is, unsurprisingly, that taking a pointer that is held inside a boost::shared_ptr, dynamic_casting it down the hierarchy and then stuffing it into another boost::shared_ptr is a good way to ensure double deletion. Oops. So, if you see the following code you better get the debugger out...

   boost::shared_ptr<A> something(new A(blah));
   ...
   boost::shared_ptr<B> something_else(dynamic_cast<B>(something.get()));

So far so bad, but I couldn't believe that something with a flaw that obvious would be in the boost libraries. And of course, there is a way around this - boost provides alternatives to the four C++ casts with similar names that work on boost::shared_ptrs. You can find these alternatives - which are really just wrappers around the C++ casts, but designed to work with the boost smart pointers - in the include file boost/pointer_cast.hpp.. If you're using smart pointers because you need polymorphic behaviour of, say, items stored in standard C++ containers, have a look at this page right now. If you don't have the time or inclination to check the linked document right now, the management summary is: "The next time someone tells you that you can't use boost:.shared_ptr with dynamic_cast, point them in the direction of boost::dynamic_pointer_cast". Using boost::dynamic_pointer_cast would change the above example to:

   boost::shared_ptr<A> something(new A(blah));
   ...
   boost::shared_ptr<B> something_else =
      boost::dynamic_pointer_cast<B>(something));

Problem solved.

For someone who supposedly sucks at math this is a pretty good blog post on math, computers and wonderful issues you can run into: Coding Horror: Why Do Computers Suck at Math?

The links, especially "What Every Computer Scientist Should Know About Floating-Point math" are well worth reading, too.

I've finally bit the bullet and stuck my various Emacs third-party libraries under version control in subversion. I don't normally modify third-party packages that I use but this allows me to quickly sync my Emacs configurations between machines. In order to make this work as smoothly as I intend it to work, there is one job left to do and that would be to create a common dot-emacs file that gets loaded by the local variants so I can have both some basic common customisations and machine-specific configurations at the same time.

While collecting all the Emacs packages that I want to put under version control I've also updated the weblogger mode that I use for my initial blog posting when I'm posting out of Emacs - the workflow looks something like writing post in Emacs using weblogger.el, post to the blog as a draft, then do the final editing and cleaning up in Serendipity's built-in editor. The version of weblogger.el I'm using is the version by Tom Robinson that's mentioned on EmacsWiki. I'm not using weblogger mode exclusively - I've also got the ScribeFire extension for Firefox installed, which is very handy if I just want to throw out a quick post linking to someone else's blog post - but I do like the combination of weblogger mode with Flyspell-mode and Auto-fill as they add up to a very useful text-only blogging solution.

Yes, this is another one of these "put it on my blog lest I forget what I did" posts.

There are quite a lot of blog posts about this, pretty much all of them centred around the required change to the system preferences that you need to make in order to use the unsupported devices (ie, not a Time Capsule or another Mac). I'm currently backing up onto a FreeBSD server via Samba after following the instructions here. The command line needed to create the sparse bundle used to hold the backup didn't work for me on Mac OS X 10.5.6 but with the help of the manpage, I created the following one that worked for me:

hdiutil create -size $SIZE -fs HFS+J -type SPARSEBUNDLE -volname $MACHINE_MAC_ADDRESS.sparsebundle $MACHINE_MAC_ADDRESS.sparsebundle

And yes, I realise that it probably wasn't necessary to give the volume and the sparse bundle directory the same name...

This looks like a big step in the right direction. As Herb Sutter repeatedly pointed out, writing correct parallel programs is a lot harder than writing a correct sequential program so a compiler that can take over part of the work is definitely a good thing.

I just saw this article on Herb Sutter's blog: RIP: SD Conferences « Sutter’s Mill

This is not good. I've attended SD West several times in the past and always enjoyed it. A good place to recharge your batteries after a year of working in your own little niche. I actually didn't attend this year's conference as the conference program looked rather cut down compared to the previous years and I couldn't really see enough interesting sessions to justify the cost of flying out there. I had hoped for a better programme at the autumn conference in Boston, but that now turns out to be a misplaced hope. A pity.

RIP SD, you've changed my life in more ways than a mere programming conference should...

In other, better news, Scott Meyers has been awarded the Dr Dobbs 2009 Excellence in Programming Award. Congratulations!

After the second Information Week with Dr Dobbs Report put in an appearance a few days ago I'm pretty much convinced that I will not renew that particular subscription as I certainly don't feel like I am part of the target audience anymore. This is a pity as I certainly was part of the target audience of Dr Dobbs Journal in the past.

Given that I have seen my favourite programming magazines disappear over time - first C++ Report, then C/C++ Users Journal, now Dr Dobbs - and am now a little short of my monthly reading fix, does anybody have a recommendation for a good programming magazine that covers a wide range of topics?

I've blogged about the the demise of Dr Dobbs Journal as a print publication before. As I am a subscriber, the promised replacement in form of an issue of Information Week with Dr Dobbs report tacked on recently turned up in the mail. No emails regarding a new digital edition so far, though. I hope these emails havn't been caught in a spam filter, so if anyone has heard anything regarding a new digital issue, please let me know.

Anyway, back to the Dr Dobbs Report section in Information Week. Unfortunately the section - which is about virtualization - seems to be targeted at the same audience that the rest of IW is targeted at, namely CIOs and the like. I diligently read through it but there was only very little in there that I'd consider useful for a working programmer like me. That is a pity as the normal Dr Dobbs always contained a few articles that I found interesting, even if they weren't necessarily applicable to my day to day work. It doesn't come as a great surprise, but obviously I'm not massively pleased to have yet another good programming publication pulled out from underneath me and either not replaced at all (as with the C/C++ Users Journal - I don't think the promised additional content materialised in Dr Dobbs) or replaced with something rather unsuitable.

I'm hoping that there will be a digital issue soon and that it's back to its usual quality, otherwise I guess that this will be another subscription that goes into the bin. For the time being I'll be sticking to Communications of the ACM, ACM Queue and c't for my CS, programming and hardware fix...

While I can understand from a business point of view that magazines which do not generate enough revenue to make enough of a profit to stay alive have to be closed down, I'm beginning to wonder where developers will get information about new concepts from - book sales are down, there are fewer programming related magazines, etc. I don't really think that blogs are the answer to that either - there is only so much you can put into an blog post unless you're Steve Yegge, and while it's a good way to pick up fixes for immediate problems from blogs, Stack Overflow and through the usual Google searches, I think we're losing a valuable distribution mechanism here.

I've mentioned this in a couple of posts recently - basically posting to this serendipity blog via XML-RPC strips out the '<' and '>', which in turn renders all HTML formatting that I post from external clients pretty much useless. It turns out that I triggered the whole problem myself when I recently upgraded libxml2 and PHP on this server and ran straight into a known PHP/libxml2 interaction bug. Took me a few hours wandering around the serendipity forums to find the hint but I got there in the end.

I guess I'll have to wait until an upgraded PHP is available for the server to fix the problem.

I've believe I'm mentioned before that a lot of the projects I work on are cross-platform. Several of them are developed mainly on Linux with only a few changes are being made on Windows. On one of these projects I noticed that several test that are part of its test suite were failing when run on Windows but worked fine on Linux. Not only that, but they also failed with odd error messages.

Strangely enough they were failing in the test setup routines, all of which worked perfectly well on Linux. Not that they were massively complicated either, as they were just loading a configuration file or two. Nevertheless the load operation worked fine on Linux and promptly failed on Windows.