Not really. We are in.. unviolent agreement it seems.

It’s always great to experience an outbreak of harmony on the web, especially having spent the years before HTML and the pretty image-laden web reading comp.* newsgroups with perhaps more than their fair share of CAPITALISED posts flying around.

I was thus delighted to see Benjamin Friedlin’s response to my gentle prod

The concept of performance, especially in the context of things like real time matrix pricing engines, is one that causes me endless fascination.

Go on, go on…

I have talked to quite a few different people about this issue, both verbally and virtually, and I have heard all ranges of opinion from people who are looking into designing ASICs to implement pricing algorithms in hardware (and I thought assembler was a scary maintenance proposition) through the likes of Benjamin who prefer to stick to languages like C/C++ to people who have implemented in java, but performed strange contortions to make sure their applications generate no garbage to avoid GC kicking in at all (some even looking for ways to turn off the collector) {Benjamin: I must admit that I have almost never seen J2EE involved in this kind of scenario}

It’s true, there do seem to be a variety of favored approaches, and I’m inclined to think they are more driven by the familiarity of their authoring practitioners than by what is the best way forward. I’d like to correct Peter in one place however. Although I favor C++ for such applications, I am an even bigger fan of even more esoteric methods, such as using SSEx assembly instructions and to go several steps further, using the GPU. My thoughts on those two methods however will be saved for another day.

The conclusion; there is no conclusion, certainly no right answer. As with every dimension of an engineering solution, you can only define performance with respect to the problem space. The only certainty is that - whatever your performance criteria - you cannot test performance into an application at the end of the development cycle. Build bits, performance test often and optimise as part of your development process (I’d love to hear people’s experiences of this cycle with the logic in an ASIC!) Sorry if that’s stating the blindingly obvious…

You’re forgiven! In all seriousness, I think Peter raises a good strategy when he suggests that one does frequent performance testing. Unfortunately in my experience I have not seen quant teams driven to do much performance testing. A lot of these desks are driven by one manager who’s in turn driven by measuring performance on returns. Certainly you’d think that would provide motivation for improving performance of the very algorithms that drives their trades, yet it’s rarely the case that big banks or even hedge funds want to step outside the line of the safe and proven technology of 3rd and 4th generation languages such as C++ and the managed choice of Java or .NET.

And clearly that is one of the great appeals of a vendor like Azul (Peter, don’t forget to send me that check). I think we’re going to be seeing a lot more innovation in this space and it might help to make this very debate somewhat of a moot issue.