[snackCake blog];

Semi-spoiler alert: This post will discuss the plot and themes of Life of Pi, as well as a classic film that you’ve almost certainly seen.

I just finished watching Life of Pi. I haven’t read the book, but I’ve heard quite a few times that it’s wonderful. The movie was visually stunning. Thematically, however, I was completely disappointed.

The lessons to be learned from Life of Pi, as I understand them, are:

Reason is a poor lens to see the universe through, and people who rely on it are cruel.

The truth doesn’t matter.

Since the truth doesn’t matter, you may as well choose an interesting truth.

The movie spells out rather clearIy that these lessons are most importantly applied to our religious experience and conception of G/god(s). According to its author, Yann Martell, Life of Pi can be summarized as “Life is a story… You can choose your story… A story with God is the better story.” I find this whole cocktail of Pascal, Kierkegaard, and Coexist bumper stickers pretty repulsive.

Of course, I’m not totally objective. Lesson #1 is pretty clearly a dig at someone like me, who thinks reason, skepticism, and science are all good things.

Lesson #2 may not be as personal, but it’s much uglier. The truth does matter; It’s what moors us the world around us.  And the truth, while sometimes impossibly elusive, is beautiful.

If we reject lesson #2, then the premise supporting lesson #3 is gone. However, I will say that when we find ourselves unable to find The Truth, we are best advised to not only choose the truth that is most reasonable, but to also admit that our truth may be wrong.

All of this brings me around to another film about a man who suffers the loss of his family and finds himself isolated. He also chooses his truth, to grimmer and far less inspiring results.  Norman Bates and Pi may seem quite different, but in a sense, they are two sides of the same coin.

I really can't get enough of this article by "militant dipshit" Deepak Chopra.  He is attempting to prove that skeptics who call him and his associates out on their scams are censoring him, by way of a painful analogy to Game of Thrones.

"Like the [Night's Watch], these militants haven't actually looked over the wall, and given their absolute conviction that the human brain is the only source of awareness in the universe...".

This analogy is fantastic for two reasons:

In the very first chapter of Game of Thrones, the rangers of the Night's Watch are north of the wall.

In Deepak's analogy, he is an undead monster intent on destroying civilization (presumably, this is him), and his enemies are the knights who are protecting it.

Apple's Objective-C Automatic Reference Counting (ARC) is a big improvement in developer efficiency relative to the manual reference count system that used to be standard in Objective-C.  However, it still has considerable shortfalls compared to the Garbage Collection (GC) systems used by Java, C#, and many other languages.

For example, with ARC, it's possible to:

Leak memory by creating strong reference cycles in blocks or delegates.

Inadvertently nil out weak references to view objects that aren't initially included in the view hierarchy.

Overrelease objects whose retain pattern confuses ARC, such as NSInvocation return values.

Of course, all of these issues can be avoided by a careful developer, but time spent thinking about weak and strong references or debugging issues that arise from their misuse is time not spent building useful functionality in your software.

The tradeoff for this extra work, however, is purportedly better performance.  Apple has claimed that ARC is faster than GC, and even faster than manual reference counting.  That being said, given the convenience of GC relative to ARC, I had to wonder: Is a little performance boost worth it?

In addition, Xamarin, an alternative cross-platform development environment based in C#, has a new, Generational GC engine.  Maybe with advancements in GC technology, the gap between GC and ARC isn't that big anymore.  I didn't find any useful data comparing Xamarin's C# GC and Apple's Objective-C ARC and decided to do a comparison.

I had a few simple goals for this comparison:

Isolate the performance of memory management, instead of comparing overall performance of Xamarin C# and Objective-C.

Allocate lots of small objects to allow ARC and GC to dominate CPU time.  For sake of comparison and curiosity, however, I also wanted to see how relative performance would scale when allocating a smaller number of large objects.

Use standard Foundation objects, to objectively simulate the mix of memory allocations that will occur in an iOS app.

Operate on a background thread to avoid interference with the main runloop.

For both ARC and GC, three simple tests were performed.  All tests iterated over the creation of 3 objects (NSMutableData, NSMutableArray, NSMutableSet), and assigned the objects to strong property references (Objective-C) or private fields (C#).  The tests differed only in the number of loops performed, and the size (capacity) of the objects allocated:

Small Capacity - 50,000 iterations, 1 object capacity

Medium Capacity - 5,000 iterations,  1024 object capacity

Large Capacity - 500 iterations, 10,485,760 object capacity

Test Results

I ran each test a number of times, and while the results varied a little, the results below were typical.  All results are reported as the number of seconds to complete the test.

Ouch.  Keep in mind that my goal in this test was to find out whether GC was close enough to ARC that ARC wasn't really worth the development headache.  The results definitely dashed those hopes.

Remember that allocating a large number of small objects was the test  that should most clearly demonstrate the relative performance of ARC and GC.  In that test, ARC is 46 times faster than GC.  Again, Ouch.  In the medium test, ARC is actually 55 times faster.  In the large test, where we might expect the task of allocation to overwhelm reference counting and garbage collection, ARC is still 15 times faster.

Given the staggering performance difference between the two, I wanted to know if there was something else going on.  I decided to create another comparison that I thought might be more favorable to C#, although it wouldn't be nearly as direct a comparison of the memory management system.  Instead of creating Foundation objects on both platforms, this test created C# / Mono objects (MemoryStream, ArrayList, Dictionary), in the C# app and equivalent Objective-C / Foundation (NSMutableData, NSMutableArray, NSMutableDictionary) objects in the Objective-C app.  The same iteration counts and capacities as the original tests were used for the small, medium, and large tests.

These results start out looking a lot better for C# garbage collection.  In this case, ARC is only 1.8 times faster in the small test.  In the medium test, however, ARC is almost 12 times faster.  In the large test, however, things got truly ugly for GC: The application crashed (every time) with an OutOfMemoryException.

One last test finally showed a ray of hope for the GC app, however.  In my initial testing, all test runs (Foundation / Mono objects, small / medium / large capacities) were performed during a single launch of the application.  I found that if the Mono / small test is run as soon as the application is launched, it actually runs a hair faster (0.85 seconds) than the ARC / small   test.

Conclusions

Given the wide variety of results represented in this comparison, it's hard to draw a single conclusion.  However, the following conclusions are fairly safe:

The performance gap between Objective-C ARC and Xamarin C# GC is not small.  In some cases, performance is similar, but when memory usage is stressed, ARC is orders of magnitude faster.

While GC is generally a more "developer friendly" and "low maintenance" solution, it isn't foolproof.  The ARC app never crashed due to a memory error, or for any other reason.  The GC app, however, crashed every time the Mono / large test was performed.

GC was actually a bit faster than ARC in the case where small Mono objects were allocated immediately after application launch, but nearly twice as slow when run after other tests.  This result makes sense, given the nature of ARC and GC.  Because GC doesn't make any effort to clear memory when the application is busy and there isn't excessive memory pressure, it is actually able to "skip" some of the work of memory management.  However, when multiple tests are run, memory pressure will build, forcing expensive GC operations, and causing erratic performance.  ARC, on the other hand, will keep memory pressure low the entire time by immediately releasing memory, so performance is consistent and predictable.

The Code

The code used in this test won't win any awards for OO design, UX, or pretty much anything.  Both apps are quick hacks, whose sole purpose was to test performance.

Objective-C ARC

C# GC

Test Configuration

iPhone 4S

iOS 6.1.3

XCode 4.6.1

Xamarin Studio 4.0.3

"Release" build profile used for C# and Objective-C versions

All other applications closed while the tests were run

Caveats

Allocating arbitrary blocks of data on a loop and then not doing anything with them obviously isn't representative of real world application behavior.  However, this comparison wasn't meant to look at real world behavior; It was meant to isolate the relative performance of ARC and GC.

I'm not a C# developer.  My strategy for porting the Objective-C code to C# was to pretend I was porting to Java, then capitalize things and fix compilation errors.

I used the free Xamarin "Starter" edition.  The starter edition didn't allow me to profile the application to see where it was spending time.  It also didn't appear to have the option to actually turn on the fancy new generational garbage collector, so it was most likely using an older garbage collector.

There was something else going during in The Clone Wars, I never noticed it until the other day. The Jedi Council claim to be the moral center of the great, democratic Galactic Republic, but let's examine that claim for a minute.

When the Jedi arrived on Tatooine and found Anakin Skywalker, they were reasonably unable to free both Anakin and his mother from slavery.  However, in the intervening years, while Anakin was being trained as a Jedi, neither the Republic or the Jedi Council made any attempt to free Shmi Skywalker, or any of the other slaves on Tatooine and the other outer rim systems.

In typical imperialist fashion, they were happy to exploit the resources (human, in this case) of less developed systems, while failing to bring the democracy they claim to hold so dear.  It has been said that the question of whether one human being (or Toydarian) can own another is one of the most obvious moral questions that can be asked, and while the Republic may officially outlaw slavery within their borders, their de facto support of it in the outer rim demonstrates a clear failure on this count.

After the onset of The Clone Wars, our assessment of the moral standing the Republic can only grow more grim.  Faced with an army of Droids, the Republic, in collusion with the Jedi Council, employed a massive army of clone soldiers to defend a Republic that is apparently too indifferent to its own destruction to defend itself.  The absolutely reprehensible nature of this act cannot be overstated.  The republic made use of human beings who were born into military slavery, to defend a populace that would not defend itself, with the full support of the Jedi Council.  No government that would engage in an evil of this magnitude can reasonably be expected to survive, much less claim a position of moral authority.