LNK2019

Every C++ dev gets bitten by unresolved symbols in their builds from time to time. You can stare at code for hours, sure that your library is defining a symbol. I just cracked one of these. Three methods in a lib were showing as unresolved when I built the exe. This stackoverflow entry was helpful, especially Raymond Chen’s blog entry which put me onto the undname utility. I’ve known about dumpbin for years, but undname was new to me. The problem turned out to be that one of my libs was built without the STLport headers on the include path. Visual Studio silently picks up its own STL. Then the linker complains it can’t resolve methods that return an std::string. The unresolved refs all had stlp_ in the signatures. Of course, I couldn’t see that until I compared methods defined in the lib using dumpbin /linkmembers:2 and undname with those unresolved by the linker.

LMAX conference

So I’ve signed myself for the LMAX UCL algo trading conference – see you there !  I’m looking forward to Martin Thompson’s talk, and hoping I can bend his ear on a few server engineering questions over drinks at the end of the afternoon. I’m also keen to know more about the LMAX market design. In the infoq presentation I linked earlier there are some intriguing comments about ensuring low and stable latency for market makers. This makes me wonder what the terms are for market maker participation on the LMAX order books. Do market makers have a different API than market takers ? Do makers get processing priority for placing, pulling and amending orders ? Can maker orders cross with other maker orders, or only market taker orders ?

Finished Sussex’s LIFFE

Sussex discusses the shift from LIFEE to Eurex for the Bund contract towards the end of the book, but doesn’t offer any special insight. There’s a few comments on the Eurex Flipper too, and how he angered locals on Eurex by kidding money out of them. One could argue that the locals were kidding money out of the ‘real’ market participants. Having worked as a local at times, that’s not Sussex’s point of view. All in all, an enjoyable read, albeit without eureka moments.

Debugging Twisted Matrix networking code

Debugging Twisted code is an exercise in lateral thinking. The error messages and exceptions can be opaque, especially when code wrapped inside a Deferred fails. When you get an unhandled error inside a Deferred, check your code for basic errors: parameter mismatches, references to undefined variables, or unimported types or modules etc. And where you’re deriving from a Twisted base class, check that you’re not accidently overriding a member variable. For instance, don’t have a member variable called ‘clients’ !

Sussex’s LIFFE

In Day One Trader John Sussex recounts being on the floor for the Queen’s visit to LIFFE in 1992. The Queen is greeted with spontaneous applause from the traders – Sussex contrasts the reception with that given to Tory Chancellor Ken Clark, who was met with chants of “who ate all the  pies ?” And shouts of “you fat bastard!”

Day One Trader

At the moment I’m enjoying John Sussex’s career memoir Day One Trader. He stumbled into the City as a 16 year old Essex lad, and ended up on the board of LIFFE. I’m interested in exchange trading, and there’s lots of good anecdotage on how brokers, dealers and locals worked order on the floor. I’m looking forward to Sussex’s account of the late 90s, and the battle with Eurex and the development of LIFFE Connect.

LMAX Disrupter

This presentation from two LMAX guys was recommended to me by a couple of friends. I watched it last night, and was very impressed. The topic is high throughput, low latency server engineering. There’s a lot on what it takes to make Java go really quick, and how to work with the hardware in a sympathetic fashion. They recommend one thread for business logic, and dedicated threads for messaging and persistence. This runs counter to the conventional Java wisdom, which tends to involve pools of worker threads executing the same logic and using locking. It’s an approach I’ve had success with in hybrid C++ Python server processes: put all the biz logic on a single Python thread, and handle pub/sub messaging and persistence on C++ threads.

What I found really new and exciting about the LMAX Disrupter pattern they advocate was the use of ring buffers for lock free cross thread comms. I used queues for thread to thread comms in my C++ Python processes. As the LMAX guys point out, those queues use locking. LMAX Disrupter uses atomic CAS instructions for cross thread comms, so that the comms done with the ring buffer are lock free.

All in all it’s a brilliant and insightful presentation…