For most situations, the stock 1080mAh, 7.4V batteries that come with the Canon T1i¹ will work pretty well. In some other instances, including time-lapse and star-trail, that amount of power doesn’t cut it. For these types of photography, either the camera needs to be on but inactive for a long period of time, or needs to have the sensor enabled for a long exposure. When I last used my T1i for a long exposure, the 1800mAh extended battery pack I used lost power after about 3 hours, giving an approximate power need of 600mA while the sensor was exposed.²

To get around this battery life problem, Canon provides an AC/DC power supply and coupler that you can use to power the camera. Unfortunately an AC power supply requires a connection to the power grid, a generator, or a power inverter. In the middle of the Adirondacks where I am most likely to do long-exposure photography, an AC connection is just not feasible and a power inverter is inefficient. There are also professional battery packs that can be purchased specifically for astrophotographers, but the couple I found were prohibitively expensive. The third option was to use a battery grip provided by canon, but at $180 for just the grip, I was convinced there was a cheaper option.

This led me to the realization that I already had on hand an Energizer XPAL XP18000 battery pack. I use it when I travel on long trips as an extra battery for my laptop and charger for my cell phone. This pack is light and portable at only about 17 ounces and less than 8 inches long and 1 inch thich and comes with a bunch of connectors for laptops, cellphones, and other gadgets. That 18000 in the name indicates that the battery stores 18,000mAh of power and sports 3 different outputs in varied voltages (5V, 10.5V, and 19V). Since I already had a nicely powerful battery pack, I determined I’d use it to power my camera.

Unfortunately, I needed to regulate the voltage. My Canon T1i is rated to take an input of 8.1V DC. The camera will accept 10.5V DC, but doing so is dangerous, may break sensitive components in the camera, cause fires, physical harm, or worse: void your warranty. I don’t recommend you do it, and if you do over-volt your camera, you do so at your own risk. After searching around, however, I found that some earlier enthusiasts had succeeded in making a DC/DC power supply for their own cameras. Resolving to do the same, I pulled together everything I needed to build the power source.

Combining resources I found from Daniel McCauley and Texas Instruments, I determined the circuit I would need to build out the module. At the center of it all, and hardest to get a hold of, was the PTN78020W module which actually does the conversion. This module accepts up to 36V as an input and can output anywhere from 2.5V to 12.5V. Of the other electrical components mentioned in the parts list, most are recommended to ensure the power in and out of the regulator is free of noise. Consult TI’s official documentation to ensure that, if you use fewer components, you include the mandatory capacitors in the correct locations.³

Because I don’t have the skills to produce a custom board myself, and since fabricating a single circuit board is not cost effective, I used a standard solderless breadboard which fit in my enclosure.⁴ For the input, I used a 2.1mm(ID)/5.5mm(OD) jack which mates perfectly with the base 19V cable included with the XPAL battery pack.⁵ For the output, I picked my own jack/plug combination since I needed to make a cord to go from the power supply to the camera’s DC coupler.⁶

After assembling all the components as described in the electrical diagram, installing the plugs into the enclosure and soldering things together, the project looked as pictured. Of special note is that the PTN78020W does not fit easily into the breadboard. I had to bend several of the leads to get it to sit properly. I don’t recommend this, as you are likely to end up with a $30 (retail) broken module and nothing to show for it.

Once it was all put together, I used a multimeter to verify that I was getting the desired voltage out. I was able to verify that I was hitting my target 8.1V very closely, and once I hooked it up to the camera, I was showing a “full” battery. I used it this past weekend when I attempted a 4-hour long exposure (unfortunately I had the exposure misread, and didn’t get the result I wanted). After the 4-hours taking photos with the LCD viewscreen enabled, I hadn’t even exhausted a quarter of the XPAL battery’s power.

As an after-exercise, I downloaded a circuit board CAD program from Pad2Pad—they fabricate custom circuit boards and prototypes—and designed my own circuit board. Unfortunately, as I said before, it’s not cost effective for me to purchase a single board, but if I get some interest in this, I’d certainly purchase several and manufacture the power supplies myself and ship one to you. The price I’m looking at, which includes the power supply and 6-foot cord connecting to the DR-E5 is $70. This price is about the same as the mass-produced AC power supply provided by Canon, so the $70 price is a value for the hand-manufacturing. You can buy the DR-E5 coupler for around $30 on Amazon (see link below). If you already have an AC adapter, then you are likely to already own this coupler. If you’re interested in an 8V DC/DC power supply (or 12V for your Canon 1D, or other custom voltage), send me an email: photo+power@xpdm.us.

Disclaimer: I’m not an electrical engineer. I have not vetted this design with an electrical engineer. I am an amateur who loves photography and found a tool to continue to improve my art. Completion of this project is done at your own risk to yourself and camera. If you take issue with the circuit or anything else, feel free to leave a comment.

Parts List

Part IDs in parenthesis lead to Digi-Key parts.

• Resistors
• R₁: 3.9kΩ 5% 1/4W (3.9KQBK-ND)
• R₂: 2.7kΩ 5% 1/4W (2.7KQBK-ND)
• R_set: 5.9kΩ 1% 1/4W (5.9KXBK-ND)
• Inductors
• I_1–3: 3.9µH (M8316-ND)
• Capacitors
• C₁: 1µF 50V Ceramic (445-2889-ND)
• C₂: 2.2µF 50V Ceramic (478-4472-ND)
• C₃: 330µF 50V Electrolytic (P11258-ND)
• C₄: 470µF 16V Electrolytic (338-1751-ND)
• C₅: 1µF 25V Ceramic (445-2857-ND)
• C₆: 100µF 25V Electrolytic (P11258-ND)
• Diodes
• D₁: Schottky 40V 1A (1N5819DICT-ND)
• LED_1–2: Red Panel Mount LED (L10061-ND)
• Voltage Regulator
• PTN78020WAH (296-20515-ND)

1. 1800mAh for the 5DmII, 2300mAh 11.1V for the 1DmIV [↩]
2. This is just an estimate. For a D60, Daniel McCauley measured 400mA required while the shutter was open. See his 8V power supply guide, on which this one is based. Variations will also occur with the ambient temperature as well, so your mileage may vary. [↩]
3. The power supply doesn’t work optimally if there is electrical noise on the input side. Also, because the PTN78020 is a switching voltage regulator, it introduces electrical noise at the frequency of its internal switching. [↩]
4. It is important to note that the PTN72080WAH module does not sit well into the standard breadboard. I had to “adjust” a few of the leads so that it could fit into the breadboard’s grid at all. This is why I would much prefer manufacturing the printed circuit board I mention later in this article. [↩]
5. I chose the 19V output because the PTN78020 module requires a voltage difference of at least +2.5V from the target output voltage. Using the 10.5V output puts me right at that limit, and I’d rather have a large buffer to avoid undervolting the module. [↩]
6. The DR-E5 coupler requires a 1.1mm(ID)/3.0mm(OD) right angle plug. The right angle is tight, and it took me a good deal of searching to find a plug with a short enough lead to fit in the confined space. The jack/plug I used on the other end of the cable was a 1.3mm(ID)/3.5mm(OD) which happens to fit into the 9-12V plug on the XPAL battery pack. [↩]

Over the past several months, I have really stepped up my photography to a serious level. In that time, I’ve been dabbling in landscape, portrait, music, journalistic, and model photography. Recently, though, I had the opportunity to be a part of a show put on by Music Ecology. Each month, they put on a Visual Enlightenment party at the Wonder Bar in Allston, MA.

I was one of six artists that were selected to have our artwork hang in the bar during the month of July. On the right above, you can see the layout I chose to go with and clicking on the image will link to a gallery where you can see larger versions of photographs.

I chose to have a couple of themes run through the display. At the top are two fall images from northern New York. In the center is a photograph (featured) of the New England Holocaust Memorial where a person’s face (my friend Justin Kwan) stands as the backdrop to the ID numbers given to prisoners in the concentration camps. On the right are a couple of animal photographs with very narrow depth of field, bringing extreme sharpness to the faces of the sparrow and turtle.

The smaller photographs arrayed around the main centerpiece include a lead crystal car sitting on a reflective black tile. On the top left (featured), Scott Strazzullo plays his guitar during the Songwriters’ Night at All Asia Bar in Cambridge¹. On the top right, a 15-minute exposure (with the help of an ND400 filter) of one of my company’s week’s-end “workshops”. On each side in the middle are book pictures. To the left, the Bible, Square, and Compasses of my mother lodge, Mt. Horeb. To the right, a book of magic tricks turned to a page showing a coin trick.

The bottom three are of special interest to me, and I’ve singled out one to the left here. All three are of the Champlain Bridge, also known as the Crown Point Bridge. Or, rather, they were. As I mentioned in my earlier post, the bridge was demolished on December 28, 2009. The photograph on the left shows the bridge as it was on the somber morning of its demolition. The center (featured) and right photos show the deconstruction and ruins left behind by its demolition. This weekend, I’m going to be back up in New York and plan to extend the series, getting additional photographs of the deconstruction and re-construction process.

All in all, the staff at Wonder Bar were great and very accommodating to my layout whims. I really want to thank them, Music Ecology, and Polina Volchek in particular for organizing it. All of the my prints are on sale as are several of the other artists on display there. If you are interested in purchasing a print, you can do so either through my online gallery or by emailing me directly at photo@xpdm.us.

1. You can see other photographs from that night in a gallery dedicated to the June 2010 Songwriters’ Night at All Asia Bar, including photos and video of Jourdan Rystrom and Norman Kim. [↩]

This past weekend I was lucky enough to be spending my Christmas holiday with my wife’s family in the North Country in New York. For those of you that don’t know, the North Country is that region of New York and Vermont from about the Lake George area to the Canadian border. I’m not originally from the North Country, so that might be a bit off, but certainly just saying Upstate New York would not have been sufficient. I say I’m lucky because I had the opportunity to be present for a rare event, and had my camera along to document it.

The event I speak of was that the Champlain Bridge (also known as the Crown Point Bridge) was finally going to be demolished after a spiral fracture had been found in one of its concrete support piers. That fracture led to the bridge’s closing on October 16, 2009. The closing of the Champlain Bridge had vast implications in the region; the nearest bridge into Vermont is 50 miles south of Crown Point in Whitehall, and the nearest bridge north of Crown Point is over 100 miles away at Rouses Point. In between, Lake Champlain is serviced by several ferries, but only one of them operates 24 hours a day, and none of them are open to industrial traffic.

With the bridge condemned, a vital link for many individuals and companies on either side of the lake was severed. People living on opposite sides from where they worked faced an extra 2-4 hours of travel to and from work, and trailers would be forced to detour many miles to get to the same location.

The Champlain Bridge, which was dedicated and opened on August 26, 1929, was demolished with explosives 80 years later on December 26, 2009.

The morning of the demolition was cold, snowy, and visibility was very poor. None but those with permission to access the Crown Point location, and perhaps some from Vermont were actually able to see the bridge implode. For most of the public waiting to see the bridge’s final moments, all that was seen was fog punctuated by the series of bursts indicating that the charges had gone off.

The afternoon before and morning of the demolition, I set out and took several pictures at the scene, but, lacking a media pass, did not get a photograph of the actual implosion. Meanwhile, you can see the somber and eerie photographs of the Champlain Bridge in its waining days on my Flickr account in my Champlain Bridge Demolition set.

The replacement bridge is expected to be in place and opened in the summer of 2011¹.

All pictures in the aforementioned set (with the exception of the “Protection” meta-photo) were taken with the following lens, which I highly recommend:

1. NYSDOT’s current schedule for the Lake Champlain Bridge Project [↩]

There was a time when one bit per pixel was enough. Back in that time, there was only one color channel with only one value for each pixel; either on or off. One bit per pixel was sufficient. Next came progressively more graduated gray-scale, up to the 256 levels provided by a one-byte, eight-bit value. This was about the period that I got my first computer, an Apple IIc in all of it’s green-display glory.

Then color came along: red, green, and blue. Now those 8 bits were rationed out; three to green and red and two to blue in the common case¹. Then came 16-bit color, followed by 24-bit color. Now red, green, and blue were on equal footing, each holding 8 bits of information. Soon after came the cake-is-a-lie 32-bit color, which is rarely adds anything more than 24-bit color².

This brings us to today, where most computer monitors advertise the 16.7 million colors afforded by 24-bits of color data. For most of us, this is plenty, as the human eye is estimated to only be able to distinguish 10 million colors. Thus, 8-bits per channel is generally sufficient for displays and is why there haven’t been any big pushes to extend that range³. The issue is no longer one of how many colors but of how broad a gamut of colors.

The standard gamut used in most displays is called sRGB. sRGB is a rather limited gamut but one that has such wide acceptance that, in the absence of any information to the contrary, it is the assumed default for images. It’s a form of least-common-denominator for electronic displays. For most uses that involve a computer display as the means of consumption, using sRGB is sufficient. However, sRGB lacks the ability to represent saturated yellows, greens, and cyans. This shortcoming is readily apparent when it comes to printing images. The printer has a different gamut for CMYK. Some colors that are in sRGB aren’t in CMYK and visa versa. The more saturated blues and yellows that CMYK can print but aren’t represented in sRGB can leave images of the sky and flowers a little under-saturated.

In order to handle the wider range of colors, alternative color spaces must be used with wider gamuts. Examples include Adobe RGB (1998), PhotoPro RGB⁴, and Adobe Wide Gamut RGB. These gamuts allow even more colors to be represented.

Or do they… In an analog system, sure; just as the cardinality of the set of real numbers, , is greater than the cardinality of the set of rational numbers, , so too, the number colors in Adobe Wide Gamut RGB is greater than the number of colors in sRGB in addition to containing all of sRGB even though all those sets have an uncountable number of members.

However, in the digital format, each component is chunked into quanta. For 8-bits, there are 256 distinct values. When you expand the gamut, the number of representable colors remains exactly the same (256), but the distance between quanta of color is larger. Think of it as taking a 24-inch ruler and stretching it. The ruler covers more distance, but there are still only 24 sections on it. There is just more distance between each hash.

When this extended gamut is invariably cast back into a smaller gamut, such as sRGB, the lack of color data resolution causes a phenomenon called posterization. If you’ve ever used 8-bit mode during a remote session on your 24-bit desktop, you’ve seen this effect. The combined effect is somewhat similar to a rounding error.

One way to combat this posterization is to increase the resolution of the color data, e.g. from 8 to 16 bits per channel. With 256 times as many hash marks on the color ruler, the color gamut can easily be expanded to twice its size without causing the banding effect.

As most digital cameras still capture in sRGB and output to 8-bit JPEG, the common photographer has nothing to worry about, but for the more advanced photographer who wishes to have more control over their output, a larger gamut, such as Adobe RGB, and greater resolution are more important. My camera, the Canon Rebel T1i (pictured below) offers an output to RAW format⁵. Each pixel of the sensor has 14-bits of resolution, so it makes little sense to use a working format with less bits per channel. Thus, after importing the RAW file, my working format is Adobe RGB with a 16-bit TIFF. The TIFF format is an uncompressed beast, but it ensures that I don’t lose any of that color data in translation.

Getting the results that you want can be cannily uncomplicated. Most photographers aren’t even worrying about all this as nearly all decision making, aside from composition, is made inside the camera. But when more control is desired, the entire workflow needs to be insulated from introducing error into the process so that the end result is precisely what the photographer intended. And it’s at this time when eight bits really isn’t enough.

1. The reason being that green is primary color to which human eyes are most sensitive, and small changes in green are more easily noted than in red or blue. This fact is further utilized by many steganographic programs which embed information in image files. [↩]
2. There are some 32-bit color implementations that use 30 bits (10 bits per color), but most commonly, the extra 8 bits are used for non-color data or padding. In fact, Windows 7 will support up to 48-bit color, but no graphics cards yet support it; only a few graphics cards currently support 10-bit-per-channel color; and, fewer still monitors can display the 1 billion+ colors available with 30-bit color. [↩]
3. Though, as mentioned in the previous footnote, Windows 7 is breaching that ceiling. Read more about the advance of digital color resolution on Wikipedia [↩]
4. Which uses an ‘imaginary’ blue as one of its primary colors. [↩]
5. A proprietary version of the TIFF format; each manufacturer often has their own proprietary extensions. [↩]

This Saturday is Square and Compasses Day in Massachusetts. S&C Day is a state-wide open house organized by Freemasons across Massachusetts to offer the public the opportunity to learn more about the fraternity.

My lodge, Mount Horeb Lodge in Woburn, will be holding its open house from 0900 to 1500 on Saturday, October 17. If you happen to live in the area, I encourage you to come out and see what there is to see. We’ll have the entire building open and members from three lodges will be there giving tours around and about the lodge. There is a ton of history within the Masons, my lodge was established in 1855, and we have some great historians who can explain much of what we have done and continue to do.

In addition to tours of the Masonic lodge, Children’s Hospital of Boston will be outside taking blood donations for their children. The more that donate, the more lives are saved. One donation can save the lives of as many as three people! You can schedule an appointment, if you’d like, by calling 781-933-8220 and pressing 2, but walk-ins are also much appreciated.

Whether you want to find out more about the Masons, eat a hot dog, help save a life, or just jump on a bouncy castle, join me at the Woburn Masonic Apartments at 17 Arlington Road in Woburn. If you don’t live near Woburn, check out the Grand Lodge website to find a lodge near you. Everything is free, and you’ll certainly learn something new for your time. Feel free to contact me for more information at marcus@griep.us.

I’ve finally uploaded a first batch of pictures from the StackOverflow DevDays in Boston. Out of over 350 pictures taken, only 20 made it to this cut, with several not-quite-as-good pictures that I may look at adding later. If you see any you’d like, let me know, and I’ll get a proper copy to you.

Taking photos at the event was very difficult. For human eyes, everything was fine, but for a camera’s lens, there was very little light. I didn’t use flash during the event; a common courtesy to both presenters and audience in an already low-light environment. It made me really wish that I had a 50mm f/1.4 lens like this one, though; too bad such wide aperture lenses are so expensive!

The other environmental difficulty for photography was all of the different light source types. There were fluorescent lights in the main area (blueish), recessed incandescent bulbs (redish-orange), and the projector light (near 6500K, or like-sunlight). So, in the picture at right, for example, the main subject, Joel Spolsky, was standing under incandescent lights. This gives him a redish-tinge. When correcting Joel’s white shirt back to white, the slides in the background, having a neutral tint before correction, end up tending toward blue after.

Regardless, I’m happy with the photos I did get. Again, feel free to check them out. Here’s the link in case you didn’t catch it earlier!

My StackOverflow DevDays Flickr Set

StackOverflow DevDays day in Boston was very fun, well planned, and well executed, with a nice array of speakers from across a wide swath of the development world.

The day started off with a keynote speech by Joel Spolsky. His talk was very amusing, and included a theory that all work boils down to a use case wherein the goal is to get the end-user laid, or is in furtherance of that end goal. He further went on to discuss the two objectives of simplicity and power, and that whereas they may seem diametrically opposed, there is money to be made in reconciling simplicity (Don’t make me decide on things I don’t care about) and power (I want to be able to do this and that and some from column C).

From there, the main scheduled presenters took over. Ned Batchelder¹ gave a good presentation on the Python programming language. Although I have been used to programming in Python for quite some time, I very much enjoyed the talk which used a Python spell checker as a demonstration of the features of the language. The talk moved at a good pace that was still interesting to me as someone who already knew the material, but also didn’t seem to leave anybody out in the code.

After Ned was Dan Pilone². Dan’s presentation focused on the iPhone development experience, and moved methodically through the most pertinent points, from XCode to Instruments and the Interface Builder, to the application submission process (denoted by slide showing a despairing man in a desert crying out as sand slips from his grasp), to the sales and marketing mentality necessary in Apple’s App Store. Humor tossed in at a few key places made this an enjoyable and solid overview, which is what it was. If you were looking for an in-depth look, then the one-hour format would leave you disappointed, but from outside iPhone development looking in, the presentation fit the time and audience well.

Just before lunch, Joel Spolsky³ retook the stage using 30 minutes to demo the latest version of FogBugz, FogBugz 7, the flagship product of his company, FogCreek. FogBugz includes a new feature in this version, which I’ll briefly mention called Kiln. Kiln is a new integrated and hosted source control⁴ and code review management service going into beta as of the announcement. If it piques your interest, you can check it out on FogCreek’s website.

After a lunch⁵ Patrick Hynds and Chris Bowen⁶ presented on ASP.NET MVC. Their talk was good, though there were points where it sounded like cheerleading rather than a technical talk. To be fair, Chris Bowen is a developer evangelist for Microsoft, so it’s not unexpected, and it could have just been the “view from my seat”. The subject matter was good; I walked away convinced that Microsoft had done quite well with their MVC implementation.

John Resig⁷ was the next presenter, and the creator of the jQuery JavaScript library. His talk focused around the need for testing in JavaScript. He focused on several different frameworks for testing, as well as different methodologies from in-browser unit testing to mocking out the entire browser with an out-of-browser solution like Env.JS, to behavioral testing and functional testing.

John did a good job impressing the difficulty of testing JavaScript in a manner that spans the majority of all browsers and indicated that, in his opinion, there’s nothing like real-world testing, with a real human. He pointed to Test Swarm as a distributed example of how to get in-browser testing across a wide array of user/browser configurations. Overall, a good spanning overview that didn’t get mired in the gritty details of each framework, but just enough to understand where each had its use.

The last presenter of the day was Miguel de Icaza⁸ presented on Mono. I spoke with him briefly at lunch, and even then, he was still vacillating as to the subject matter for his talk. The actual talk was mildly haphazard as a result, but the flow worked well with Miguel’s free personality. He took the audience through Mono Tools for Visual Studio, showing remote debugging from a Windows VS session to a program running on a remote SUSE Linux VM. From there, he went a step further, building an RPM of the ASP.NET MVC sample blog engine. Next, he uploaded that RPM to SUSE Studio and generated a VMWare image in ~10 minutes, fully configured, and was running the blog engine in Mono’s ASP.NET MVC.

Miguel also showcased MonoTouch, building a simple program in MonoDevelop on Mac OSX, and demonstrating it in the iPhone simulator. Including lots of pro-Linux banter and some pokes at Richard Stallman, Miguel kept the audience interested and amused, which is exactly what the last presentation in an 8-hour day needs.

On the whole, the StackOverflow DevDays conference was well done. I enjoyed myself even in those areas outside my expertise, and came away having learned something. Be prepared for a few advertisements for FogCreek during the breaks (well put together and enjoyable, but advertisements no less), but as the co-founder of StackOverflow is also a founder of FogCreek, it’s not un-expected. Was it worth my $99? I believe so. Do I recommend you go? If you have the time, and there’s a location near you, then yes; check out the list of scheduled speakers for your event and see if there are any you’d be interested in.

As I mentioned in my preview, I took many pictures of the event, but have not had a chance to process them yet. I hope to do so tonight and have something to post by this evening.

UPDATE: My first batch of pictures is now up. Check them out on my Flickr account and read my photographs article.

1. Ned’s DevDays blog post, including slides. On Twitter: @NedBat [↩]
2. On twitter: @danpilone [↩]
3. On Twitter: @Spolsky [↩]
4. The only hosted source control option is Mercurial; I didn’t get a chance to ask Joel why only Mercurial, though he assured us there were several reasons. [↩]
5. Provided lunches included turkey or beef sandwiches or a veggie wrap along with a half-ounce bag of chips, apple, and cookie [↩]
6. On Twitter: @ChrisBowen [↩]
7. On Twitter: @jresig [↩]
8. On Twitter: @migueldeicaza [↩]

If you’re like me, then you listen to a lot of NPR. Every Saturday at 1100, my radio turns on to listen to the crazy mechanics “Click & Clack” on Car Talk followed by Wait, Wait… Don’t Tell Me! at noon¹. Wait, Wait…, a weekly news quiz show, is a great way to pull some humor out of both the mundane and the off-beat news of the week wherein everyone’s ultimate goal is to get Carl Kasell‘s voice on their home answering machine. Yesterday, Peter Segal, the host of the show, announced that Wait, Wait… has decided to enter the blogosphere.

We’ve been following this “web-log” thing for a while… waiting to see if it was just another one of those internet² fads, like dancing babies or keyboard cats or histories of dance. Dances. But it seems to be sticking, so we here at Wait, Wait thought it would be worth a try.

I’m intrigued. It’ll be another outlet for news humor that for one reason or another didn’t make it to air; a supplement between doses of Peter Segal, Mo Rocca, Paula Poundstone, Amy Dickinson, and all the other panelists.

You can also keep up with the Wait, Wait… crew on Twitter via @waitwait³.

1. I’m a member of NPR member station WBUR 90.9 Boston [↩]
2. Sic. The pedant in me wants to point out that Internet should be capitalized. [↩]
3. Various panelist Twitter accounts: @morocca, @paulapoundstone, @askingamy, @TomBodett, @KyrieMeMo, @adameft, and @petersagal [↩]

Tomorrow, October 7, I’ll be headed to the StackOverflow DevDays in Boston. I’m especially excited to see Joel Spolsky and Miguel de Icaza.

I’ve been a fan of Joel’s insights, even if I don’t always agree. In my senior year of college, I received a copy of his book, The Best Software Writing I as an interview gift. In that book, Joel pulls together some great articles written by a very diverse group of people, all bringing their own insight to the world of software. When I began doing interviews from the “other side of the table”, I also found Smart and Gets Things Done to be a great read. Joel will be presenting on his company’s primary product FogBugz.

At the end of the day, Miguel will be presenting on something to do with Mono. Because Mono is such a “giant universe”, Miguel has solicited feedback as to which Mono topic should be the focus. I’m interested to hear about MonoTouch¹ and Mono.Simd. There are a lot of value-added ways in which Mono differentiates itself, yet compliments, the .NET framework from Microsoft; I’m looking forward to hearing about the future of these and more developments.

Other topics to be presented include Python, the iPhone, ASP.NET MVC, and JavaScript testing. Although it’s late, if you feel inclined, tickets can still be obtained for the event ($99 each), and registration is at 0800. WiFi is also being provided free of charge, so I’ll probably post an update during the event.

I’ll be bringing along my camera to take some photos, which I’ll be posting on Flickr after the event². If you see me around, feel free to introduce yourself or pose for a picture.

UPDATE: My first batch of pictures is now up. Check them out on my Flickr account and read my photographs article.

1. Think the Mono/.NET framework and C# brought to the iPhone and iPod Touch. [↩]
2. Right now, you’ll only see a picture of Lucy, my cat, from when she was a kitten. [↩]

In my previous article, I took a look at some of the framework considerations and alignment in Mono.Simd. Getting back to my experiment, I’ve been getting respectable results from my SIMD implementation of Threefish256. Threefish256Simd was taking approximately 20% longer than the Fajardo reference implementation, but something had to be holding the SIMD version back.

Looking back to the machine code, I found that even aligned loads via the API from arrays were coming back pretty slowly with a number of extra moves and extraneous temporary variable. So, I eliminated the pre-calculated key schedule altogether in favor of calculating the key permutations on the fly as in Fajardo’s implementation. With some specially crafted local vectors for the key and tweak values, this changed the key permutation lines in my prior listed source to look something like this¹:

bB = bB + k1 + t0h;
bA = bB + bB + k0 + t1l;

Later subkeys add in a subkey counter as noted in the Skein specification.

With these changes made, I re-ran my tests. This was the optimization I needed. The SIMD-enabled Threefish256 algorithm was now running in less than half the execution time of the reference implementation: 3.8 ns to 9.3 ns. I had been able to significantly beat my hypothesis.

Output of test/timing program²

mgriep@metis:~$ mono-2.4 mono -O=all,-shared Program.exe
Encrypt:
61773FAC03A37433 B1EFF698BC88802B 22A47D9E7D7F8005 1EC6162F214FB0EC
61773FAC03A37433 B1EFF698BC88802B 22A47D9E7D7F8005 1EC6162F214FB0EC
Good!
Cross Decrypt:
0000000000000000 0000000000000001 0000000000000002 0000000000000003
0000000000000000 0000000000000001 0000000000000002 0000000000000003
Good!
Speed test of 100000000 iterations with an unroll of 100
Encryption:
Non Simd: 00:15:49.8701366, Average: 00:00:00.0000094
    Simd: 00:06:39.0892858, Average: 00:00:00.0000039
Speedup with parallelism = 2: 2.38009430570386
Efficiency: 1.19004715285193
Decryption:
Non Simd: 00:15:40.1476703, Average: 00:00:00.0000094
    Simd: 00:06:29.0575232, Average: 00:00:00.0000038
Speedup with parallelism = 2: 2.41647472221403
Efficiency: 1.20823736110702
Overhead: 00:00:00.0026434, Average: 00:00:00

The speedup, approximately 2.4, equates to an efficiency of 120%. This is a super-linear speedup for degree of parallelism equal to two. I assumed parallelism = 2 because two long integer operations can take place simultaneously through the XMM registers. Just moving to the XMM registers incurs some additional overhead, so a super-linear speedup was unexpected.

The extra speedup came from a combination of architecture and the Threefish algorithm. Specifically, Threefish operates on 64-bit words. As my computer was 32-bit, long integer operations are broken up by the main processor into multiple micro-ops and therefore isn’t quite as efficient as on a 64-bit processor.

Thus, by moving the arithmetic out of the integer processor and onto the SSE processor, I was able to gain the benefit of the larger word width. Add to this the parallelism gained by performing two operations at a time, and subtract the overhead from moving data into and out of the XMM registers, and you get the exhibited performance.

While I haven’t tested on the 64-bit platform, I would expect the SIMD version to be faster, but not by as much on the 32-bit platform, since the larger word width would eat some of the efficiency gain from moving onto the SSE processor.

Overall, I was very happy with the experience developing with Mono.Simd. There are several things that I would love to see added or changed (aligned moves by default, alignable objects, the psllq %xmm1,%xmm0 instruction³ exposed). Nonetheless, the API is still evolving, and I expect I’ll find myself contributing a few patches to scratch some of the itches I’ve come across.

I hope that you’ve found this an interesting walkthrough of my first experience with Mono.Simd. If you want to inspect my code in more detail, check out my xpdm Github repository. You’ll find Threefish256Simd under the Xpdm.Security.Cryptography namespace⁴. I’d love to hear about your experiences with Mono.Simd, if any be had!

1. Redundant LoadAligned and StoreAligned calls have been removed for readability [↩]
2. This output was created with the Skein v1.1 specification on an EeePC 900A with an x86 Intel Atom processor. [↩]
3. psllq %xmm1,%xmm0 is a packed quadword (long) logical shift left where the components of XMM0 are shifted left the number of bits specified by the respective component in XMM1. [↩]
4. The code has not yet been updated to use the new Skein v1.2 rotation constants [↩]