GitHub Work Culture (people change jobs because of burn out, how to prevent burn out while still working hard?)

A colleague pointed me at this little meme: http://vimeo.com/43676958

Most company work spaces would destroy what they have to say as dangerous, claiming that it would never work.  The interesting thing is that it does work for GitHub, and it works very well.

For me it reminds me of something a very good manager once taught me; the role of a manager is to create and protect the environment and culture for productive software development. It only takes one manager to ignore that advise to damage or destroy the soul of a work place and GitHub has pushed back hard against that decay in thought provoking ways.

Zeebox nominated for T3 Best App of the Year award

If you have been enjoying zeebox this year, then please vote for us in the T3 awards. To do so, just click  here.

Java Modulo vs Bitmask benchmarks

We all like things to run fast. A well known optimisation for ring buffers, consistent hashes and hash tables alike is to replace the modulo operator with a bitmask. The trick being to keep the length of the arrays to being a power of two. Thus replacing a costly operation with a much cheaper one. The question that I wanted to answer here is not whether this optimisation works, but on the Java stack how much of a difference does it make. The following timings were taken running JDK 1.6.0_31 on a 2GHz hyper threaded quad core MacBook, which repeated each operation from cold ten million times each. The table shows that so long as the array length is a multiple of two then hotspot will eventually replace % with & making this optimisation only worth applying to speed up the pre-optimisation window. It also shows that the speed up is roughly a factor of three.

	Min (ms)	Max (ms)	Per Iteration
v % 5	174.812	273.81	1.5ns
v % 4	68.684	127.508	0.6ns before hotspot, 0.4ns after
v & 3	64.45	89.134	0.4ns

Conclusion: When using % n, aim to have n to a power of two. This gave a threefold performance improvement within this benchmark.  The interesting result here is that Hotspot is capable of optimising the modulo operator, rewriting it to a bitmask for us on the fly so long as the division is to the power of two.

Appendium (May 2013): Over the last year I have learnt more about how Intel CPUs are structured, and a few interesting facts have emerged. Firstly a divide instruction takes approximately 80 CPU cycles to execute (ouch!) and can be pipelined at the throughput rate of 20-30 cycles. This is compared to a logical AND which takes 1 cycle to execute, and has a throughput of 0.5.  It also turns out that only one of the CPU ports is capable of performing division but multiple are capable of bitmasks.  Thus using a bitmask is not only much faster than division but more of them may be run in parallel too.   CPU time taken from x86 Optimisation guide (checkout table C-16 in the appendices).  This level of parallelism was not seen in this microbenchmark because the instructions were all modifying the same data.  Also note that this benchmark focused on measuring throughput interlaced with additions and for loop iteration rather than instruction latency; thus hiding some of the cost of performing a division.

View the benchmark code

Using Spin Locks to simplify unit testing of async code

A common barrier to working with concurrent code is having confidence in it. It can be difficult to unit test. The most common solution is to generate events that the unit test can hook in to. However that adds complexity and sometimes it is either too difficult, muddy or just not desirable. In those cases a simpler tool is the good old spin lock. Below is a Scala wrapper around the JUnit assertEquals method that keeps retrying a condition until it is true. If that condition is not true within n milliseconds then the test fails. Simple, but effective.

  def assertEqualsWithRetry[T]( expected:T, actual: => T, maxDurationMillis:Int=5000 ) {
    val startMillis    = System.currentTimeMillis()
    def durationMillis = System.currentTimeMillis() - startMillis

    while ( durationMillis < maxDurationMillis && expected != actual ) {
      Thread.`yield`()
    }

    assertEquals( expected, actual )
  }

Zeebox, ranked number 6 media application above Facebook

The top ten media apps of 2011

Not a bad result for a product that took 3 months of development before its first release on the iPad and has not even been released outside of the UK yet. 2012 is going to be a big year for us!

Handling Java nulls in Scala

Null handling in Scala can be painful, to ease this pain I like to avoid the problem entirely by not using them at all. However sometimes one has to cross talk between Java and Scala, and then one has to face the problem head on.

The cleanest approach that I have found, that does not result in a deranged mix of generics or implicits is to use an anti corruption layer as close to Java as possible that converts Java's use of null into an Option as soon as possible.

For example:

    Option(o).map(_.asInstanceOf[T])

If o is null, then the above snippet will evaluate to None, else Some(o).

String Option with map and closures is rarely readable, at least not until you have bathed in it for long enough to have Scala'ized your mind. So I like to wrap this up with a function, as follows.

  def asInstanceOfNbl[T]( o:AnyRef ) : Option[T] = Option(o).map(_.asInstanceOf[T])

IntelliJ vs Scala [The Battle Rages On: A productivity tip]

Following a short discussion yesterday at work, about how Intellij keeps changing scala keywords to Java class name while you are typing. Forcing you to break flow, go back and correct it (swear) and then continue. I dug around the IntelliJ settings and found the following very useful setting. In Java it works wonders, in Scala it is just plain irksome.

Settings->Editor->Code Completion->Preselect the first option

When writing Scala, set it to 'Never'. The Scala keywords val and override will never be quite as annoying again ;)