1. A single thread can increment a static field 1.5 billion times in 4 seconds.
2. Two threads that update a static field runs slightly slower than 4 seconds probably due to the locking overhead.
3. Two threads that use Interlocked.Increment to update a shared field takes 52 seconds!! Why is it so slow?
4. Two threads that update a ThreadStatic field takes 2.5 seconds. Of course this isn’t a global counter, but it sets a baseline for performance.
5. Two threads that update separate fields takes 3.7 seconds. Why? Probably because of cache contention.
6. Two threads that update separate fields on different cache lines takes 2 seconds. A cache line is 64 bytes, or 8 long fields. So I added 7 long fields to force the 2 counter fields on different cache lines.
7. Same as #6, but use an array of counters rather than fields. Now takes 8 seconds. Is this because of bounds checking?
8. Same as #6, but use CompareExchange (CAS) to update fields, takes 22 seconds. There’s no contention and it always succeeds. Why is this operation so insanely expensive? It’s supposed to be a single machine op on x86.

Notice how small implementation differences result in giant performance gaps. Updating separate cache lines is important for speed, but I still need to sum the values to return the current count. Cliff Click has a clever implementation in Java here. However, it still relies on CAS to perform updates which will, on .NET at least, slow down performance by 10X. This post from Joe Duffy confirms that CAS operations are expensive. I suppose if these designs scale to a large number of threads then it’s worthwhile. But if it sucks for a few threads then it’s unusable for most programmers.

Or are they? I assume the pictures are still on the drive somewhere. If I can somehow mount the drive I might be able to recover them. The jailbreak program greenpois0n published their exploit code called syringe. It says that the jailbreak can expose the filesystem. If I can mount the filesystem in Linux, perhaps using libimobiledevice, I can scan the drive and recover the pictures. There’s some technical information on iOS and jailbreaking available here. This is one of those rare moments when my CS degree may actually be useful.

Perhaps an alternative is to use Twitter as a PuSH message bus. When a PuSH hub detects an update it can send a direct message to the subscriber’s Twitter feed. Subscribers can use Twitter’s user streaming api to fetch and process these direct messages. The advantage is that Twitter queues the messages until you log in to grab them, and it has a decent streaming API for pushing lots of messages quickly to the subscribers. No need to reinvent the wheel when it’s available for free.

To create lots of branches in bzr, it’s better to create a shared repository first. Go into that directory and make a branch that mirrors the main branch. Then make branches for develop and other features. After you’ve made some commits on a branch, go to the branch you want to merge the changes into. Then call merge from the feature branch into the main branch to add those commits. Fix any merge problems and call commit. This will not do a fast forward merge; instead, it preserves the branch info in the history.

  > bzr init-repo project
  > cd project
  > bzr branch /path/to/master
  > bzr branch master develop
  > bzr branch develop feature1
    ... hack on feature 1 ...
  > cd develop
  > bzr merge ../feature1
  > bzr commit

local=/home/
expand-hosts
no-resolv
strict-order
server=208.67.222.222
server=208.67.222.220

I actually like last.fm, but I do wish I could pick and choose tracks occasionally. I also would like offline access on both my laptop and iPods. Pandora is nice, but seems to cycle through the same songs and artists a bit too often. I’m going to try Rdio and Mog soon. Now I just need to pipe all this music through my stereo somehow.

AWS can be programmatically controlled via APIs exposed as web services. There are many, many tools that offer easier access to these APIs. To do anything interesting, you have to write a complex script to accomplish a high-level goal, i.e. deploy new web servers, backup a database, expand a tier, run a new DB slave, etc. You will often end up with lots of scripts to do this or that because these scripts are imperative (a sequence of steps to achieve a goal). The scripts are imperative because the languages (Java, Python, Ruby) are imperative (the OO just makes it modular).

With Prolog I hope to build, in effect, a script generator. My Prolog code right now can query AWS and load in the initial state: all available instances, volumes, snapshots, security groups, etc. in your account. The programmer only needs to define the goal state: the way you want your AWS deployment to look. Given the appropriate rules, Prolog should be able to find a way to accomplish this goal by figuring out what set of AWS calls it should make. It is basically generating the scripts for you.

A simple example would be a goal state shutdown: no instances should be running. Let’s say right now there are 4 running servers. The Prolog system will see these 4 servers and call terminate-instance for each one. Simple, right?

A less simple example might be replicate-zone: copy the current deployment in zone A to a new availability zone B. Again the Prolog code will look at what you’ve got in zone A. Then it will try to launch the same instances in zone B.

A more complex example might be “run my website for under $100/month”. The system might explore deploying spot instances, launching 1 larger instance rather than 3 smaller ones, or whatever. It will somehow manage your resources to fit within a budget.

I’ll post my code soon, but it is a barely functional minimal prototype right now. There are lots of interesting issues to deal with like data modeling, expressing rules, inventing a DCG grammar. I’m confident it will work eventually.

The basic idea is quite simple. You need to pass a structure along with each call that contains a Guid to correlate a particular path through the system. In addition, you need to recreate the call hierarchy by passing along a parent ID (the calling service) and a child’s ID. The IDs are like pointers to reconstruct the call graph. The root service will not have a parent id. Each service dumps all this info to their own local trace log. A trace line should look something like this:

Guid, Service name, Method name, Parent ID, My ID, Timestamp, other optional data

Another monitoring process should gather all these trace logs from all machines and dump them into a database. Now you can do queries per Guid where you reconstruct the call graph and explore the performance of your entire distributed system. You should be able to gather the information in near real-time, depending on the load of your system. And if you run a high-performance site, then just trace 1 out of every 100 or 1000 calls (sampling).

Ideally, a tool like this would be integrated into your runtime so you don’t need to manually manage the Guids and trace info. It looks like dynaTrace does exactly this. Otherwise, you could integrate this into WCF by attaching a header to every SOAP message containing the Guid and parent/child IDs. I think it might be possible to use Sessions in WCF to add this information, though it may impose additional overheads. Nevertheless, this is very useful stuff and I wouldn’t want to run a production system without these profile traces.