[Beowulf] Pricing and Trading Networks: Down is Up, Left is Right

[Joe Landman]

On 02/18/2012 11:12 AM, Andrew Piskorski wrote:

> You've worked in the financial trading world so long and have talked
> with so many different (successful) traders, that a guess based on
> your own experience might well be reasonable?  Oh wait, you've never
> done anything remotely like that.

FWIW: our customers in this market all say the same thing in terms of 
"Time To Market" and correctness/maintainability.  It sucks if your code 
is write once.  Its bad if it takes you N months to deploy something 
that a competitor can deploy in N weeks (or N days).

What we are seeing (from customers) are mixes of C/C++ and a number of 
domain specific languages (DSL), as well as "scripting" languages which 
have JIT compilers or JIT->VM execution paths.  Java is one of these, as 
well as a few others.

Oddly, I haven't seen so much Python in this, a little Perl, and zero 
Ruby.  The languages that are in use are very interesting (the well 
known ones), and the ones that aren't as well known or are private DSLs 
are pretty darn cool.  There is much to be said for a language that 
enables an ease of expression of an algorithm, and doesn't get in your 
way with housekeeping and language bureaucracy crap.

Understand that I am a fan of more terse languages, and the ones that 
force you into massive over-keyboarding (cough cough ... where's my 
coffee) should just have a nice '#include "boring_stuff.inc"' to 
simplify them.

> The only plausible way you could know that is if you've been reading
> lots of comprehensive academic and/or industry surveys (if they exist)
> of traders.  Sounds interesting.  So how about you point us to the
> best summary of all that data on what sort of strategies traders say
> they use?  I'm sure there must be one, because you wouldn't just be
> making wild assertions unsupported by any evidence whatsoever, right?

Heh ...

/stands up to give a good takedown ovation ...

There's lots of (mis)information out there on what HF* (multiple 
different types of high frequency trading ... not just equities) 
implies.  The naive view is that the only thing that matters is speed of 
execution.  As we service this market, we aren't directly involved in 
day to day elements of the participants coding, but we are aware of 
(some) issues that impact it.

> Joachim, thanks for chiming in with observations based on your
> real-world experience.  It's nice to see some piece of Vincent's rants
> occasionally inspire worthwhile content.  Jim Lux, you too, even more
> so; I've learned interesting tidbits about FPGAs, etc. from your
> recent posts.

Seconded.  Nice to see some real end users speak up here (and HF* is 
most definitely a big data/HPC problem ... big HPC?).  And I always 
enjoy Jim's posts.

On silver bullets, there aren't any.  Ever.  Anyone trying to convince 
you of this is selling you something.

FPGAs are very good at some subset of problems, but they are extremely 
hard to 'program'.  Unless you get one of the "compilers" which use a 
virtual CPU of some sort to execute the code ... in which case you are 
giving up a majority of your usable performance anyway.  And if someone 
from Convey or Mitrionics v2 wants to jump in and call BS (and even 
better, say something interesting on how you can avoid giving up the 
performance), I'd love to see/hear this.  FPGAs have become something of 
a "red headed stepchild" of accelerators.  The tasks they are good for, 
they are very good for.  But getting near optimal performance is hard 
(based upon my past experience/knowledge ... more than 1 year old), and 
usually violates the "minimize time to market" criterion.

If you have a problem which will change infrequently, and doesn't 
involve too much DP floating point, and lots of integer ops ... FPGAs 
might be a great fit technologically, though the other aspects have to 
be taken into account.

Joe

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: landman at scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/sicluster
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615