All in all worked out very well, and it seems to do exactly what it promises. The support for sub-states is useful to cut down on config bloat by defining common transitions on a parent state.

If I were to nitpick it would have been nice to see generics used to avoid needing to cast the entities/events, however this would arguably bloat the Tungsten source somewhat. It would have also been nice to be able to specify an “ignore” type transition which could be specified on a parent state to ignore an event rather than having to define transitions on all sub states of the parent state for an event in order to ignore it and stay in the same state.

Overall a lot of the things discussed were things that we were already aware of as a team, and although it was disappointing not to have any huge takeaways from the day it was heartening to know that our team is at pace with the current state of the art (although clearly the state of the art as presented predominately by vendors at such a conference does not necessarily equal the true state of the art in in-house technologies developed by banks/funds).

A few interesting themes from the day:

• Integration/Standards – A lot of interest in making proprietary components e.g. for risk/algorithmic execution use industry standards (e.g. FIXatdl for algo trading) to speed up integration and facilitate reuse of off the shelf components.
• Build vs buy – Many of the panel discussions focused around this with the vendors obviously arguing the buy case for time to market, less developers required etc.
• Interest in low-latency/HFT increasingly spreading to FX/options – According to the vendors, a lot of the technologies previously used almost exclusively by equities such as InfiniBand/10 GigE and colocation are now being taken up by increasing numbers of customers for FX/options.
• The need for education – One of the panel members made an interesting point that a lot of customers have infrastructure teams who have no idea what the High Frequency Trading teams in their bank are doing, this can be counter-productive as the HFT teams build/support everything themselves as they don’t feel they can trust the infrastructure teams to understand/implement their requirements correctly. If infrastructure teams were better educated about HFT/low-latency this would be less of an issue.
• Different types of latency – Darshan Chandarana from Oracle address touched on realtime JVMs a bit and re-iterated the fact that it is generally not possible to have both the lowest latency and maximum determinism – realtime technologies generally decrease variance at the expense of increasing  the mean. The only counterexample given to this was InfiniBand, which apparently is indeed a magic bullet!

A few interesting vendors:

• Panopticon – Partners of Sybase’s CEP offering (Aleri), they demoed alongside Sybase. Some interesting visualisations on top of the risk system (e.g. their treemap).
• Sumerian – Came up with a nice sound byte in one of the panel discussions: “Latency is a distribution, not a number”. This piqued my interest as this was a view that our team hold which some of the other latency monitoring vendors we have previously met didn’t implement. Also, unlike some of the other vendors we have previously met, Sumerian’s approach is not a real-time dashboard – instead data is shipped to them and they analyse it to produce a one-off report which identifies which areas of the system are most latent and therefore benefit from development investment. Obviously there are pros and cons to this approach vs a real-time monitoring dashboard.
• Oracle – Thanks to the merger with Sun, they are now producing hybrid appliances using Sun hardware, e.g. they believe they have built one of the fastest database servers available (and they had brought this in an impressive display rack to their stand). Will be interesting to see if they come up with any challenges to Azul in the JVM appliance space.

Also quite useful is this blog entry which explains how to understand CMS GC logs.

Performance techniques used in the Hotspot JVM.

Normalized numbers when Base = 2, Precision = 3, Exponents = -1 to 2 [Goldberg91]

A very comprehensive paper (from which the above image is taken) is available here. In previous teams we have implemented our own functions to derive an approximation of the epsilon from the number to be represented, however I discovered recently to my surprise that such a function was added to Java in 1.5: Math.ulp!