I’ve decided to do the 2010 American Birkebeiner (skate course) despite the fact that I live in Brooklyn and I haven’t done any serious cross-country skiing in eight years. It will be a fun challenge and I got some of my more athletically-inclined family members to join me. I’m really looking forward to spending the weekend skiing with them.

The race is on February 27th, 2010, in Cable, Wisconsin. It is 50 kilometers (31 miles), with a total elevation gain of 1,398 meters. The average low temperature in Cable, Wisconsin, on February 27th is +13F and the average high temperature is +34F. The record high is +42F and the record low is -20F. Last year the low temperature on that day was -16F, with a high of +8F.

The race has an interesting history:

“It started in 1206. Birkebeiner skiers, so called for their protective birch bark leggings, skied through the treacherous mountains and rugged forests of Norway’s Osterdalen valley during the winter of 1206, smuggling the son of King Sverresson and Inga of Vartieg to safety. The flight taken during the Norwegian Civil War took the Birkebeiners and prince from Lillehammer to safety in the town of Trondheim.”

Unlike the Norwegian version of the race, skiers in the American Birkebeiner don’t typically carry a 3.5kg bag simulating the weight of an 18-month-old baby.

I train most days in Prospect Park in Brooklyn, though sometimes I run a course through Red Hook where there is little traffic and some other nice parks. Prospect Park is beautiful and full of smiling people, I always look forward to my time there. I’ll spend 2-3 weeks before the race in Duluth, MN, so that I can actually train on skis.

I used standalone talos to test a 64-bit Mac OS X build against a 32-bit build. I created the two builds using the same optimized configuration and the same mercurial revision. Since only the 32-bit build can load any of the plugins that ship with Mac OS X 10.6 I removed all plugins from the plugin search paths. This way the 32-bit build wasn’t hurt by having to deal with more plugins than the 64-bit build. The tests were done on Mac OS X 10.6.1.

Ts: 64-bit is 6.5% faster
Tp: 64-bit is 6.3% faster
Twinopen: 64-bit is 5.1% faster
Tjss: 64-bit is 8.7% faster
Tsunspider: basically a tie, 64-bit is 0.2% faster

I’m not sure what all of the factors contributing to these results are yet, but it seems Apple’s investment in optimizing the OS and developer tools for x86_64 paid off.

We got 64-bit Firefox running on Mac OS X today.

I don’t want to post a build here because there are still some significant issues. We should be ironing those out quickly though. Not all of the patches required to produce 64-bit builds are checked in yet but we’re working on it.

We had to rewrite a lot of code to get this going. Thanks to Masayuki Nakano, Joel Reymont, Markus Stange and David Anderson for helping with some of the last bugs!

Gecko 1.9.3 (mozilla-central) will only build and run on Mac OS X 10.5 or higher as of last Tuesday, September 15th. We will not be removing 10.4 code from the tree until we have verified benefits and made the decision final.

Motivations behind this move include performance, features, and development efficiency. By making Mac OS X 10.5 our minimum supported version we can upgrade our compiler to gcc-4.2 (from gcc-4.0) and use the Mac OS X 10.5 SDK. We can also use newer and more efficient technologies like Core Text, and add features like Cocoa-based printing and better international input support via Text Input Services. Since our code complexity will go down we can fix bugs and deliver features to the majority of our users faster.

We have not turned on the Core Text back-end or Cocoa-based printing yet, but we will be doing that soon.

An example of a performance win is the Dromaeo JavaScript test suite. Tests on my hardware show a 30% performance improvement from the compiler/SDK change. Tinderbox test results only show an 8% improvement, but that is still a nice win.

Building 32-bit Firefox for Mac OS X 10.6 is a little trickier than building on 10.5. This post will explain how to do it. Assume everything I don’t mention is the same as on 10.5.

First, installing mercurial via MacPorts does not work on 10.6 at this time (MacPorts bug 18449). You’ll have to install mercurial “manually,” instructions can be found on the mercurial website. You can install libidl via MacPorts as usual.

Second, Mac OS X 10.6 is 64-bit by default. Most machines will boot with a 32-bit kernel but applications included with the OS are 64-bit by default and the developer toolchain’s default architecture is x86-64. This means that in order to produce a 32-bit build of Firefox you actually have to do a cross-compile, much like the way we produce PPC builds on Intel machines. Luckily this is not too hard – simply start with the mozconfig I put in Mozilla bug 477945. If anything changes I’ll put updated mozconfigs there. The mozconfig on that bug won’t work for everyone, crashreporter is disabled (Mozilla bug 429841) and the resulting build won’t work on 10.4, but that isn’t to say that you can’t get those features when building on 10.6. You’ll just have to tweak the mozconfig as you need and file bugs when you run into problems. The mozconfig on the bug is designed to get most developers up and running quickly.

Since Mac OS X 10.6 is coming out tomorrow I thought I’d give an update on 64-bit Gecko for Mac OS X. Progress is tracked on Mozilla bug 468509.

We’re very close to having running builds. We still need to replace some old API usage related to complex text input and print dialogs, but aside from that I do not know of any other major work items. We have come a long way and we will have builds within a month. As soon as we can produce them we’ll start working on getting a 64-bit Mac OS X 10.6 tinderbox set up to produce nightly builds.

We have not made any decisions about shipping an officially supported 64-bit build for Mac OS X. I suspect at some point we will make the decision to remove the PPC architecture from our universal binary and replace it with x86-64 but like I said, we have not made any decisions yet.

Some time in 2006 a friend who was spending time in Cork Ireland sent me a partial copy of an album called “In the Moon” by a band called “Elephant.” I fell in love and ordered 3 original copies which had to be shipped to the U.S. from Cork. At the time it felt a little rash, but the album is really something and I knew the band had broken up, the album was already scarce.

Fast forward a few years. Stuart Murdoch of Belle and Sebastian released “God Help the Girl” a couple of days ago. I excitedly picked up the album on vinyl during lunch today and this evening I settled in to listen all the way through. Within seconds I recognized the new female singer’s voice – Catherine Ireton from Elephants! I always wanted to hear her do more but I didn’t think it’d ever happen. Her rendition of the classic Belle and Sebastian song “Act of the Apostle” is amazing and she’s stunning on the new title track, “God Help the Girl.” Figures that Stuart would have such excellent taste!

About a year ago I was looking at our Mac OS X XPCOM local file implementation in Gecko and I noticed that it is pretty inefficient in terms of the number of system calls it makes for some common operations. I put optimizing that on my to-do list and I’ve now committed most of the big optimizations. Here are the results.

I tested a Firefox 3.6 nightly build (6/24/2009) against Firefox 3.5rc2 by recording all of the filesystem-related system calls each build made during the course of a full standalone talos Ts run. This talos test essentially launches and quits the browser over and over again (about 23 times). I recorded the filesystem-related system calls using the following command:

sudo fs_usage -e -f filesys | grep firefox-bin > ~/Desktop/call_log.txt

The high-level result is that there were 13% fewer filesystem-related system calls made by the Firefox 3.6 nightly build (184,609 vs. 212,253). Most of my optimizations involved moving to a single “stat” system call to get information instead of using Carbon and Cocoa APIs, which often make multiple system calls, particularly if they involve using Carbon FSRefs. Given my intent, it was unsurprising that the Firefox 3.6 nightly build made 32,344 calls to “stat” vs. 15,134 calls for Firefox 3.5rc2. That is a price worth paying for having the Firefox 3.6 nightly build make only 38,250 calls to “getattrlist” vs. 98,965 calls for Firefox 3.5rc2. In case you’re unfamiliar with “getattrlist,” its man page says “you can think of getattrlist() as a seriously enhanced version of stat(2).”

Here are some other results which are interesting because they give you a good idea of how often Firefox makes certain calls. I omitted some less interesting system calls that were made fewer than 3,000 times apiece.

15,134 stat, Firefox 3.5rc2
32,344 stat, Firefox 3.6 nightly

98,965 getattrlist, Firefox 3.5rc2
38,250 getattrlist, Firefox 3.6 nightly

14,290 open, Firefox 3.5rc2
14,196 open, Firefox 3.6 nightly

9,027 write, Firefox 3.5rc2
8,649 write, Firefox 3.6 nightly

20,643 read, Firefox 3.5rc2
20,245 read, Firefox 3.6 nightly

1,325 pread, Firefox 3.5rc2
1,052 pread, Firefox 3.6 nightly

12,230 lseek, Firefox 3.5rc2
11,787 lseek, Firefox 3.6 nightly

7,692 fcntl, Firefox 3.5rc2
7,214 fcntl, Firefox 3.6 nightly

2,096 mmap, Firefox 3.5rc2
1,950 mmap, Firefox 3.6 nightly

I was recently in Arcata, CA, and I met some really awesome rabbits named Gilley and Chumley. Gilley, the girl, is 13lbs and Chumley, the boy, is 10lbs. They stay in the house and even use a litter-box. They’re super happy, especially when they get bananas for a snack in the morning. They like to play in the kitchen because the floor is slippery and they slide around. So awesome – I had no idea that people had rabbits like that for house pets! These pictures are of me feeding them bananas. Gilley licks the plate clean.

Check it out! Created by Mozilla developers Scott MacGregor and Seth Spitzer, among others.

http://www.postbox-inc.com/