On Saturday, 22 March 2014 at 13:47:31 UTC, Paulo Pinto wrote:

> Assuming those 10% still happen if the test was done today as suggested, how much are trade companies willing to pay for developers to achieve those 10% in C++ vs having a system although 10% slower,
> still fast enough for operations while saving salaries for more cheaper developers?
>

Labor is a market like any other. It depends on supply and demand. The demand is obviously high. http://dealbook.nytimes.com/2010/12/10/ex-goldman-programmer-is-convicted/?_php=true&_type=blogs&_r=0

Performance engineers who can eek out that 10% on existing systems do very well. The same engineers who can build it entirely do much better.

Thanks
Dan

On Sat, 2014-03-22 at 12:38 +0000, Daniel Davidson wrote:
> On Saturday, 22 March 2014 at 11:46:43 UTC, Russel Winder wrote:
> 
> >
> > It is also worth pointing out the LMAX Disruptor which is a
> > lock-free
> > ring buffer based framework used to create dealing platforms on
> > the JVM.
> > They outperform any other trading platform still.
> > 
> 
> That is wrong. Trading is competitive and your competitors rarely will inform you they are losing to you or beating you. And when you do not get the fills you want it is not always clear you are being beaten. This article (http://mechanical-sympathy.blogspot.com/2011/08/inter-thread-latency.html) suggests C++ version of the same architecture is faster than the Java.

If the data isn't available we'll never really know.

It is now over 9 months since the people I know left LMAX for other organizations so I have no current data, or even rumour.

It would be interesting to rerun the comparison with JDK8 and C++14. I suspect C++ may well be the winner on latency, whether by 10% I am not sure.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2014-03-22 at 14:17 +0000, Daniel Davidson wrote: […]
> Performance engineers who can eek out that 10% on existing systems do very well. The same engineers who can build it entirely do much better.

Good C++ programmers appear to be able to get $350k to $400k in NY.

Of course the effect of that good programmers can be a profit increase measures in millions.

I guess D should be able to do things just as fast as C++, at least using LDC or GDC. My little informal microbenchmarks indicate that this is the case, but for now this is anecdotal evidence not statistically significant. Sadly for a while D programmers won't be able to achieve the same remuneration as the top C++ programmers exactly because there is little demand/supply pressure.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 22 March 2014 at 13:10:46 UTC, Daniel Davidson wrote:
> Data storage for high volume would also be nice. A D implementation of HDF5, via wrappers or otherwise, would be a very useful project. Imagine how much more friendly the API could be in D. Python's tables library makes it very simple. You have to choose a language to not only process and visualize data, but store and access it as well.
>
> Thanks
> Dan

Well, I for one, would be hugely interested in such a thing.  A
nice D API to HDF5 would be a dream for my data problems.

Did you use HDF5 in your finance industry days then?  Just
curious.

TJB

On Saturday, 22 March 2014 at 14:33:02 UTC, TJB wrote:
> Well, I for one, would be hugely interested in such a thing.  A
> nice D API to HDF5 would be a dream for my data problems.
>
> Did you use HDF5 in your finance industry days then?  Just
> curious.
>

A bit. You can check out some of my C++ code generation support for hdf5 here: https://github.com/patefacio/codegen/tree/master/cpp/fcs/h5

A description of the code generation infrastructure is available here:
https://github.com/patefacio/codegen/blob/master/doc/codegen.pdf

And some python usage of tables to parse/store data for HFT analysis of potential benefits of periodic auctions as opposed to continuous markets:
https://github.com/patefacio/auction

Using hdf5 with tables and simple usage in C++ is very powerful. I did not do a lot with it - simple tables for writing/reading from C++. The API is huge and very old school, even with the C++ wrappers. IMHO an awesome project would be a rewrite in D that abandoned the API but provided file compatibility with cleaner access. D would be great for that.

> TJB

On Friday, 21 March 2014 at 22:33:37 UTC, TJB wrote:
> On Friday, 21 March 2014 at 22:28:36 UTC, Walter Bright wrote:
>> It's a good thought, but I have zero knowledge of how C++ is used for high frequency trading.
>
> I would be happy to help you with an option pricing example that
> is commonly used.  Let me know if you are interested.

This is a very interesting thread that you started. Could you flesh it out more with some example C++ that you'd like compared to D? I'm sure quite a few people would assist with a translation.

I'm not expert in high frequency trading, but I was inspired by your post to start poking around here

http://www.quantstart.com/articles/european-vanilla-option-pricing-with-c-via-monte-carlo-methods

and study some of the algorithms. Nothing there that I wouldn't rather see in D than C++.

D's GC is problematic, but the hope is that you can avoid allocating from the GC'ed heap and that eventually (soon? please?) it will be replaced by a better precise GC.

On Saturday, 22 March 2014 at 16:35:07 UTC, Brian Rogoff wrote:

> This is a very interesting thread that you started. Could you flesh it out more with some example C++ that you'd like compared to D? I'm sure quite a few people would assist with a translation.

Well, right away people jumped to high-frequency trading. Although that may be the most visible area in computational finance - it's not the only one. There are areas where performance is crucial, but where trading is done at a lower frequency (where latency is not the main issue).

>
> I'm not expert in high frequency trading, but I was inspired by your post to start poking around here
>
> http://www.quantstart.com/articles/european-vanilla-option-pricing-with-c-via-monte-carlo-methods
>
> and study some of the algorithms. Nothing there that I wouldn't rather see in D than C++.

The example that you link to is exactly what I have in mind. A simple comparison of Monte Carlo routines for pricing options would be a great place to start.

The bible on this is the book by Glasserman:

http://www.amazon.com/Financial-Engineering-Stochastic-Modelling-Probability/dp/0387004513/ref=sr_1_1?ie=UTF8&qid=1395509317&sr=8-1&keywords=monte+carlo+in+financial+engineering

And a great source for approaching this is in C++ is Joshi:

http://www.amazon.com/Patterns-Derivatives-Pricing-Mathematics-Finance/dp/0521832357/ref=sr_1_5?s=books&ie=UTF8&qid=1395509376&sr=1-5

> D's GC is problematic, but the hope is that you can avoid allocating from the GC'ed heap and that eventually (soon? please?) it will be replaced by a better precise GC.

Sounds great to me. I would love to see it. Thanks for taking interest.

On 3/22/2014 7:29 AM, Russel Winder wrote:
> I guess D should be able to do things just as fast as C++, at least
> using LDC or GDC. My little informal microbenchmarks indicate that this
> is the case, but for now this is anecdotal evidence not statistically
> significant.

Having built C++ and D compilers, I know this to be true for a fact. It's what I'll be talking about at Dconf.

On 3/22/2014 5:35 AM, Saurabh Das wrote:
> I'm quite confident that D is going to make good inroads into the
> financial industry in the coming years. Looking forward to
> Walter's talk in DConf and indeed all the talks in DConf. Wish I
> could attend - but the flight costs too much :(. Maybe next year.


C'mon, man, you gotta come. I want to hear more about the HFT stuff!

On 3/22/2014 5:56 AM, Daniel Davidson wrote:
> I don't yet see where D adds distinction to that game yet - other
> than being a great language.

Isn't that the best kind of distinction?