Tuesday, August 16, 2011

I am a bit late but more marvel from Trisha of LMAX, Dissecting the Disruptor: Demystifying Memory Barriers. How can one not love this writing?

Compilers and CPUs can re-order instructions, provided the end result is the same, to try and optimise performance. Inserting a memory barrier tells the CPU and the compiler that what happened before that command needs to stay before that command, and what happens after needs to stay after. All similarities to a trip to Vegas are entirely in your own mind.

And with diagrams.

Monday, August 15, 2011

Working with Google Protobuf DynamicMessage

Google Protobuf is an stand out project with mixed quality documentation. A corporate cynic points working with DynamicMessage, an interesting Protobuf feature lacking official documentation beyond skeletal javadoc and a short blurb.

The key trick condenses down to:

public static Descriptor descriptorFor(
        final InputStream in, final String name)
        throws IOException, DescriptorValidationException {
    final FileDescriptorSet fileDescriptorSet
            = FileDescriptorSet.parseFrom(in);
    final FileDescriptorProto fileDescriptorProto
            = fileDescriptorSet.getFile(0);
    final FileDescriptor fileDescriptor = FileDescriptor.
            buildFrom(fileDescriptorProto, new FileDescriptor[0]);
    return fileDescriptor.findMessageTypeByName(name);

// Elsewhere

final InputStream in = Class.class.
        getResourceAsStream("... your descriptors from protoc ...");
final Descriptor descriptor = descriptorFor(in,
final DynamicMessage dynamicMessage = DynamicMessage.
        parseFrom(descriptor, outer.toByteArray());
System.out.println("dynamicMessage = " + dynamicMessage);

Note the baked-in assumption of "getFile(0)", etc. The cynic's example is more forthcoming. Caveat coder.

Thursday, August 04, 2011

Avoid feature branches

Another explanation, with typically excellent illustrations, from Martin Fowler on why you should avoid feature branches.

A rewrite success story

I avoid rewriting when possible, but greenfield work is ideal: a rewrite success story from the NowJS team.

Wednesday, August 03, 2011

Monday, August 01, 2011

Exposure for Kotlin

The early signs of traction for JetBrain's Kotlin: inclusion in discussions of JVM languages.

Java v. C++, redux redux redux

Yet another Java/C++ comparison, this time for high-frequency trading, a sexy industrial programming area.

I found this quote most trenchant:

If you have a typical Java programmer and typical C++ programmer, each with a few years experience writing a typical Object Oriented Program, and you give them the same amount of time, the Java programmer is likely to have a working program earlier and will have more time to tweak the application. In this situation it is likely the Java application will be faster. IMHO.

In my experience, Java performs better at C++ at detecting code which doesn't need to be done. esp micro-benchmarks which don't do anything useful. ;) If you tune Java and C++ as far as they can go given any amount of expertise and time, the C++ program will be faster. However, given limited resources and in changing environment a dynamic language will out perform. i.e. in real world applications.

You decide.