[Beowulf] Pricing and Trading Networks: Down is Up, Left is Right
diep at xs4all.nl
Sat Feb 18 09:30:49 PST 2012
On Feb 18, 2012, at 6:02 PM, Joe Landman wrote:
> 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
> 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).
Say you produce a cpu now within 2 weeks. it's 200 watt. it's 1 gflop
and it's $100 production price
including R&D overhead, including everything except shipping to
Good idea to sell?
time to market matters for simple software engineering - not for
stuff that has to perform ok?
> What we are seeing (from customers) are mixes of C/C++ and a number of
> domain specific languages (DSL), as well as "scripting" languages
> 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
> 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
>> 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 ...
Yeah i bet some dudes want to know at which age i wrote my first
and and at which age i wrote my first trading application - but i won't.
Had you read what i posted - which you obviously never do - it would
be pretty obvious to you i had.
Also shows how total ignorant you are about performance. but let me
ask you next 3 questions:
a) when are you gonna buy a bulldozer cpu from your own cash? If so
why? And if not why not?
b) you drink of course a cola from a local supermarket isn't it, so
no pepsi nor coca cola - price matters most isn't it?
expensive wines? Time to market huh?
c) in 2003 AMD was first to market a x64 cpu, intel following with
core2 some years later. Did you buy this yourself or advice others to
- i bet like everyone on this list you get daily requests on what to
buy isn't it, so be honest
- what did you advice in 2003 and 2004 to those surrounding you?
> 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
>> 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
> 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
> they are very good for. But getting near optimal performance is hard
> (based upon my past experience/knowledge ... more than 1 year old),
> 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.
> Joseph Landman, Ph.D
> Founder and CEO
> Scalable Informatics Inc.
> email: landman at scalableinformatics.com
> web : http://scalableinformatics.com
> phone: +1 734 786 8423 x121
> fax : +1 866 888 3112
> cell : +1 734 612 4615
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin
> To change your subscription (digest mode or unsubscribe) visit
More information about the Beowulf