[Sorry if you get this post twice—let’s say that our internal builds of RapidWeaver 4.0 are still a little buggy, and I needed to re-post this ;)]

Xcode, Apple’s IDE for Mac OS X, has this neat ability to perform distributed compilations across multiple computers. The goal, of course, is to cut down on the build time. If you’re sitting at a desktop on a local network and have a Mac or two to spare, distributed builds obviously make a lot of sense: there’s a lot of untapped power that could be harnessed to speed up your build. However, there’s another scenario where distributed builds can help, and that’s if you work mainly off a laptop and occasionally join a network that has a few other Macs around. When your laptop’s offline, you can perform a distributed build with just your laptop; when your laptop’s connected to a few other Macs, they can join in the build and speed it up.

There’s one problem with idea, though, which is that distributed builds add overhead. I had a strong suspicion that a distributed build with only the local machine was a significant amount slower than a simple individual build. Since it’s all talk unless you have benchmarks, lo and behold, a few benchmarks later, I proved my suspicion right.

• Individual build: 4:50.6 (first run), 4:51.7 (second run)
• Shared network build with local machine only: 6:16.3 (first run), 6:16.3 (second run)

This was a realistic benchmark: it was a full build of RapidWeaver including all its sub-project dependencies and core plugins. The host machine is a 2GHz MacBook with 2GB of RAM. The build process includes a typical number of non-compilation phases, such running a shell script or two (which takes a few seconds), copying files to the final application bundle, etc. So, for a typical Mac desktop application project like RapidWeaver, turning on shared network builds without any extra hosts evokes a pretty hefty speed penalty: ~30% in my case. Ouch. You don’t want to leave shared network builds on when your laptop disconnects from the network. To add to the punishment, Xcode will recompile everything from scratch if you switch from individual builds to distributed builds (and vice versa), so flipping the switch when you disconnect from a network or reconnect to it is going to require a full rebuild.

Of course, there’s no point to using distributed builds if there’s only one machine participating. So, what happens when we add a 2.4GHz 20” Aluminium Intel iMac with 2GB of RAM, via Gigabit Ethernet? Unfortunately, not much:

• Individual build: 4:50.6 (first run), 4:51.7 (second run)
• Shared network build with local machine + 2.4GHz iMac: 4:46.6 (first run), 4:46.6 (second run)

You shave an entire four seconds off the build time by getting a 2.4GHz iMac to help out a 2GHz MacBook. A 1% speed increase isn’t very close to the 40% build time reduction that you’re probably hoping for. Sure, a 2.4GHz iMac is not exactly a build farm, but you’d hope for something a little better than a 1% speed improvement by doubling the horsepower, no? Gustafson’s Law strikes again: parallelism is hard, news at 11.

I also timed Xcode’s dedicated network builds (which are a little different from its shared network builds), but buggered if I know where I put the results for that. I vaguely remember that dedicated network builds was very similar to shared network builds with my two hosts, but my memory’s hazy.

So, lesson #1: there’s no point using distributed builds unless there’s usually at least one machine available to help out, otherwise your builds are just going to slow down. Lesson #2: you need to add a significant amount more CPUs to save a significant amount of time with distributed builds. A single 2.4GHz iMac doesn’t appear to help much. I’m guessing that adding a quad-core or eight-core Mac Pro to the build will help. Maybe 10 × 2GHz Intel Mac minis will help, but I’d run some benchmarks on that setup before buying a cute Mac mini build farm — perhaps the overhead of distributing the build to ten other machines is going to nullify any timing advantage you’d get from throwing another 20GHz of processors into the mix.

If you love programming, and especially if you love programming languages, there’s an episode of the Software Engineering Radio podcast that has a fantastic interview with Dick Gabriel, titled “Dick Gabriel on Lisp”. If you don’t know who Gabriel is, he’s arguably one of the more important programming language people around, is one of the founding fathers of XEmacs (neé Lucid Emacs), wrote the famous Worse is Better essay (along with a pretty cool book that I’ll personally recommend), and also gave one of the most surreal and brilliant keynotes that I’ve ever heard that received a standing ovation at HoPL III and OOPSLA.

The episode’s about fifty minutes long, and Gabriel talks about a lot more than just Lisp in the interview: among other things, he gives some major insight into the essence of object-oriented message-passing, how functions are objects and objects are functions, what continuations are, metacircularity, and the relationship between XML and S-expressions (and why XML is just a glorified half-assed version of Lisp). There’s also some great stories in the interview for computing historians: how the Common Lisp Object System was initially inspired by Scheme and the original Actor language (yep, “actors” as in “Erlang processes”), what AI research was like in the 1960s and ’70s, and the story of how John McCarthy and his students implemented the first Lisp interpreter in one night.

A wonderful interview, and well worth listening to if programming languages is your shindig.

I found this short article about law and code on builderAU rather interesting. The money quotes are the first and last paragraphs:

Technology has outpaced the legal system’s ability to regulate its use in matters of privacy and fair use rights, said Kirby… “We are moving to a point in the world where more and more law will be expressed in its effective way, not in terms of statutes solidly enacted by the parliament… but in the technology itself—code,” said Kirby.

I think that’s a great quote, and it shows that Justice Kirby has a pretty solid understanding of what code is, how it interacts with law, and that the USA’s Digital Millennium Copyright Act (DMCA)—and Australia’s Digital Agenda Act—are dangerous things. (I do think that the builderAU article emphasis on Google and Yahoo being the two culprits seem odd, although it’s hard to say this without listening to Kirby’s original speech.) I’ve always been a fan of Justice Kirby, and it’s nice to know that somebody-on-high understands that code-as-law is a problem, and it’s a complex one.

The Foundations of Open Media Software (FOMS) workshop took place last month, from the 24th to 25th of January. FOMS is a rare opportunity for open-source multimedia developers and industry folks to get together all in one place, and the result is two days of intense discussion about issues such as encapsulation formats, codecs, video and audio output APIs, media commons, and metadata—not to mention sharing a common hatred of Flash. The first FOMS was held last year in 2007, and was a great melting pot for people from very different open-source multimedia projects, such as xine, xiph.org, GStreamer and Nokia, to get together. This year’s FOMS proved to be just as successful; this time with folks from Sun, Opera and the BBC joining the fray.

One wonderful thing about this FOMS was that a large number of the xiph.org folks (Monty, Derf, Rillian, Jean-Marc and MikeS) were all there. xiph.org are one of the main providers of freely available multimedia standards, and it’s rare that their members have an opportunity to meet in person. It’s a little strange that they met in Melbourne rather than in the USA where the majority of their members are, but hey, I’m sure they won’t complaining about that!

For me, there was a bit of an ominous atmosphere leading up to FOMS due to the recent outbreaks of “discussion” in December 2007 about the HTML5 recommended video codec. (I use the one “discussion” lightly here, since it was a lot more like hearing one’s angry neighbour trying to break down a brick wall with their head, for about a week.) It seemed obvious that the HTML5 video codec problem would be discussed at length at FOMS, but I hoped that it wouldn’t dominate discussion, since there were a lot better things to do with the combined intellectual might of all the attendees than talk about issues that were mostly political and arguably largely out of their hands to solve.

I’m glad to say that the HTML5 video codec problem was definitely discussed, but with a great focus on finding a solution rather than wailing on about the problem. Ogg Theora and Dirac, represented by xiph.org and the BBC at FOMS, are two of the contenders for the HTML5 baseline video codec recommendation, and it was excellent to see that people were discussing technical aspects that may be hindering their adoption by the W3C, always keeping the bigger picture in mind.

There were also breakout groups that threw down some short-term and long-term goals for the FOMS attendees: I personally took part in a discussion about metadata, text markup of video (subtitling, closed captions, and transcriptions), and video composition and aggregation (“video mashups”). Shane Stephens would present a great talk at Linux.conf.au a few days later about Web 2.0-style community-based video remixing; if you’re interested at all in video mashups and video mixups, be sure to check out his talk!

If you’re interested at all in the open-standards multimedia space, the proceedings of FOMS are available online thanks to the FOMS A/V team, with a big thanks to Michael Dale for bringing his incredible metavid video content management system to the humble FOMS site. (You may also be interested in the W3C Video on the Web Workshop Report that was very recently released.) In an area that’s as complicated as multimedia, FOMS is tremendously valuable as a place for open-source developers to meet. It was a great complement to Linux.conf.au, and here’s hoping it’ll be on again next year!

I've finally updated my Mac OS X software list to be Leopard-aware, for those of you new to Apple's shiny little operating system. Spotting the changes between the older version and newer one is left as an exercise for the reader :-). (Boy I'm glad to have TextExtras working with garbage-collected applications on Leopard!)

Perhaps the most annoying feature of the iPhone is its recessed headphones jack:

This miserable little design decision has spawned an entire bloody industry of headphones adapters just so that you can use your own preferred set of headphones with the thing (though admittedly some headphones adapters are way cooler than others). Me, I preferred a slightly cheaper hack. And by hack, I mean hacksaw.

Process:

1. G’day, where’s the cheese?Get a kitchen knife.
2. Use kitchen knife obtained from step 1 to cut off the end of the rubber sheath at the end of your headphones plug.

Et voilà! Headphones that fit in rather nicely to that stupid jack. It also seems that a few other people have done this as well, but they applied slightly more rigourous methods than me (i.e. they used one of those “proper knives” rather than, say, a kitchen knife).

It's entirely stupid that we have to do this in the first place, but on the bright side, it does solve one of the only major annoyances I've had with the thing, which elevates the iPhone from being "pretty damn good" to "near perfect" in my eyes. One hopes that Apple won't be repeating this particular design decision for their next iPhone revision.

On the 19th of January, I left Sydney’s beautiful shores for a holiday in four parts: the Australian Open, the Foundations of Open Media Software (FOMS) conference, Linux.conf.au, and Kiwi Foo Camp. I’m in the middle of writing up about the conferences, so this is the first small blog entry in a series of four.

The Australian Open had upset-after-upset this year, being the first one in a very long time where neither the first nor second seeds made it through to the final. We had a five-day ground pass that we didn’t quite use all five days of, but still managed to catch a couple of fantastic matches on it:

• James Blake vs Marin Cilic: all brawns and no brain. There’s so much to like about two big guys always serving stuff at over 200km/h, and the only tactic is to just hit stronger and harder than the other guy. (“If violence doesn’t solve your problem, you’re not using enough of it.”)

• Hanley & Paes vs Bopanna and Ram: It’s amazing watching the top double seeds’ reaction speed at the net: you realise just how much innate talent these guys have, because no amount of training is going to make you that quick.

• The Woodies vs Pat Cash and John Fitzgerald: I’m glad I got to see Woodbridge and Woodforde play at least once in my life. Now I’d just like to see a mixed legends pair of Agassi and Graf…

• Rafael Nadal vs Jo-Wilfried Tsonga: Ah, our precious semi-finals ticket. I expected this to be a three-set match; I just didn’t think it’d be a three-set match where Nadal lost. (When was the last time Nadal lost in three sets to anybody?) Tsonga was playing quite possibly the best tennis I’ve ever seen in my life. Even The Scud playing in his best form couldn’t have matched Tsonga that night.

It’ll be interesting to see whether Lleyton Hewitt regains a better reputation amongst Australians after this year’s Open, thanks to his marathon five-set win against Marcos Baghdatis that finished at 4:33am. It’s amazing how much the media can distort reality: most people forget that Hewitt was #1 in the world for two years running, before Roger Federer came onto the scene, and is probably Australia’s best player in the past thirty to forty years. Pat Rafter never made it to #1; Pat Cash never made it to #1. Arguably Hewitt created some of the controversies himself, but I’m still amazed that so many Australians hold serious animosity toward him.

Tennis is one of those sports where watching it on TV doesn’t give you any indication of just how fast the balls are flying around, how fast a 200km/h serve really is, how fast the players are moving on the court, and how fast they’re reacting. I’m very glad to say that two friends I went with to the Australian Open had never seen a live tennis match before, and both of them loved it.

As well as plain ol’ tennis, we did of course take in a lot of the Melbourne culture, visiting many of the fine cafés and rustic alleyways in the city, heading north to the Yarra Valley for a day, going to the markets at Southbank, and eating pancakes at Stokers. One highlight was seeing James Morrison and Deni Hines at the Palms in the Crown Casino. I think our little group of four at the Palms were the youngest people in the entire audience… by about a decade. Morrison’s amusing obsession with his new vocoder keyboard and Deni Hines’s majestic voice made for a fantastic night of jazz.

All in all, my little Melbourne holiday proved to be a ton of fun and be incredibly relaxing at the same time. This was all good days indeed, since I needed a ton of energy to survive through the next week…

So now that I'm back from my f*ck-off-awesome trips to Melbourne and New Zealand (more on that later when I get a chance to blaerg about it), I am greeted with the following lovely selection of books from amazon.com:



I guess I'll be doing some bedtime reading for the next few weeks. (Note that I'm not actually a games programmer by trade—nor really a C++ programmer these days—but games coding tends to have interesting constraints such as high performance and memory management, which encourages a much better understanding of lower-level problems.) I'm a little of the way through Refactoring to Patterns, and it's great so far.

In other news, I think these three books in a row fit the definition of Alanic rather well:



Seriously, I didn't move 'em next to each other or anything. I especially love it how Java in a Nutshell looks like it's about 1,000 pages. Nutshell my arse.