On Sat, 2014-03-22 at 00:14 +0000, Daniel Davidson wrote: […]
> Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately.

I would certainly agree that (at least initially) pitching D against the Excel/Python/R/Julia/Mathematica is an easier fight. The question is how to convince someone to take the first step.

I suspect a rewrite of QuantLib in D is a bad idea, much better to create an adapter and offer it to the QuantLib folks. The ones they have already tend to be created using SWIG. JQuantLib is an attempt to rewrite QuantLib in pure Java, but I do not know if it is gaining any traction over the Java adapter to QuantLib.

The angle here to get D traction would be to have the data visualization capability: the reason for the success of SciPy, R, Julia has been very fast turnaround of changes to the models and the rendering of the results of the computations.

Certainly in bioinformatics, and I guess in finance, there is a lot of use of hardware floating point numbers, but also of arbitrary size integers, not just hardware integers. If your languages cannot calculate correctly factorial(40) then there is no hope in these domains, this is why Python, R, Julia get traction they manage integers and the use of hardware and software representations so that the programmer doesn't have to care, it all just works. This is clearly not true of C++ :-)

-- 
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

You are absolutely correct - the finance industry _wants_ to
switch away fromC++. I work in a fledgeling HFT startup firm and
we are actively pursuing D. We have tested it out in a live
trading environment and the results are very promising.

1. We are measuring better latency numbers in D (As compared to
the older C++ systems). This is good enough reason to switch :)

2. After much testing, we concluded that fear-of-GC-collects is
overblown. Avoid allocating in the main loops as far as possible.

3. Code is _much_ more maintainable and easier to understand.

4. It's fun to code again - and this point cannot be stressed
enough. C++ is a major headache but earlier we had no choice.

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.

Saurabh

On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
> Walter,
>
> I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us.  I am a Finance Professor.  I currently teach and do research in computational finance.  Might I suggest that you include some finance (say Monte Carlo options pricing) examples?  If you can get the finance industry interested in D you might see a massive adoption of the language.  Many are desperate for an alternative to C++ in that space.
>
> Just a thought.
>
> Best,
>
> TJB

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.

Thanks
Dan

Am 22.03.2014 13:38, schrieb Daniel Davidson:
> 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.
>
> Thanks
> Dan

Maybe this is a wrong conclusion, but from the comments, I would say the Java version is pretty much on par with the C++ attempts.

--
Paulo

On Saturday, 22 March 2014 at 12:35:50 UTC, Saurabh Das wrote:
> You are absolutely correct - the finance industry _wants_ to
> switch away fromC++. I work in a fledgeling HFT startup firm and
> we are actively pursuing D. We have tested it out in a live
> trading environment and the results are very promising.
>

Well, the finance industry is pretty big and therefore diverse. By, "the finance industry _wants_ to switch away from C++" I assume you mean on average or maybe those you work with. Glad to hear you are having promising results with D.

> 1. We are measuring better latency numbers in D (As compared to
> the older C++ systems). This is good enough reason to switch :)
>

You should share some of the numbers and analysis - maybe some techniques as well. Where do you suspect that edge comes from and would it be possible to duplicate the improvements by changing/improving the C++ - (not that you would want to)?

> 2. After much testing, we concluded that fear-of-GC-collects is
> overblown. Avoid allocating in the main loops as far as possible.
>

Really? Why is that... because it has no noticeable effect in your system?

> 3. Code is _much_ more maintainable and easier to understand.
>

I would bet so.

> 4. It's fun to code again - and this point cannot be stressed
> enough. C++ is a major headache but earlier we had no choice.
>

Fun is important - especially at an HFT startup. Just imagine the pain endured by new hires at firms with mounds of C++.

> I'm quite confident that D is going to make good inroads into the
> financial industry in the coming years.

My bet is it will make inroads in finance but more on the infrastructure, web, general programming side and less on the HFT, low-latency side. Probably less on the Quant side as well without something compelling. Julia is compelling with its focus on math and clear benefits over current RAD alternatives numpy, R, Matlab, etc. I don't yet see where D adds distinction to that game yet - other than being a great language.  We'll see.

Thanks
Dan

On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
> I suspect a rewrite of QuantLib in D is a bad idea, much better to
> create an adapter and offer it to the QuantLib folks. The ones they have
> already tend to be created using SWIG. JQuantLib is an attempt to
> rewrite QuantLib in pure Java, but I do not know if it is gaining any
> traction over the Java adapter to QuantLib.
>

I guess it depends on the goal. The OP was interested in replacing C++ with D for quant work. If the goal is to use QuantLib functionality in D then you are correct - wrappers are the way to go. But if you want to push D into the quant side of things and show off the benefits there are not many bragging rights to having a great wrapper over C++. I think the exercise of moving some of QuantLib to D would be the education of the benefits/drawbacks of that move and the hope it would be representative of the D vs C++ tradeoffs for quant programming in general.

> The angle here to get D traction would be to have the data visualization
> capability: the reason for the success of SciPy, R, Julia has been very
> fast turnaround of changes to the models and the rendering of the
> results of the computations.
>

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

On Saturday, 22 March 2014 at 12:54:11 UTC, Paulo Pinto wrote:
> Am 22.03.2014 13:38, schrieb Daniel Davidson:
>> 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.
>>
>> Thanks
>> Dan
>
> Maybe this is a wrong conclusion, but from the comments, I would say the Java version is pretty much on par with the C++ attempts.
>

I guess it depends where your edge comes from. If it is speed, the following suggests it is worth it to go C++. 10% is huge and reduction in variability is also huge.

[[ So what does this all mean for the Disruptor?  Basically, the latency of the Disruptor is about as low as we can get from Java.  It would be possible to get a ~10% latency improvement by moving to C++.  I’d expect a similar improvement in throughput for C++.  The main win with C++ would be the control, and therefore, the predictability that comes with it if used correctly.  The JVM gives us nice safety features like garbage collection in complex applications but we pay a little for that with the extra instructions it inserts that can be seen if you get Hotspot to dump the assembler instructions it is generating. ]]

If your edge is quickly trying out new algorithms and identifying edge by trying many less latency sensitive strategies in the market - then "pretty much on par" is a fine bar.

Thanks,
Dan

Hi Dan,



On Saturday, 22 March 2014 at 12:56:03 UTC, Daniel Davidson wrote:
> On Saturday, 22 March 2014 at 12:35:50 UTC, Saurabh Das wrote:
>> You are absolutely correct - the finance industry _wants_ to
>> switch away fromC++. I work in a fledgeling HFT startup firm and
>> we are actively pursuing D. We have tested it out in a live
>> trading environment and the results are very promising.
>>
>
> Well, the finance industry is pretty big and therefore diverse. By, "the finance industry _wants_ to switch away from C++" I assume you mean on average or maybe those you work with. Glad to hear you are having promising results with D.

Yes. The finance industry is very big and diverse. I am in particular referring to the parts of the industry that work heavily in C++ currently. Maybe my sample set is skewed because of the segment I work in - but there is a lot of enthusiasm that I have seen from those I am in contact with.

>
>> 1. We are measuring better latency numbers in D (As compared to
>> the older C++ systems). This is good enough reason to switch :)
>>
>
> You should share some of the numbers and analysis - maybe some techniques as well. Where do you suspect that edge comes from and would it be possible to duplicate the improvements by changing/improving the C++ - (not that you would want to)?

I don't think I would be allowed to share numbers :( I will check and get back on that. We have been debating about starting a blog where we can share techniques with the wider world. Unfortunately we are just so overloaded currently that getting down to doing this may take some time.

The edge for D in our case comes from 3 factors -

1. A lot of statistical data from older C++ systems means better assumptions and decisions in the new D system; and

2. 20% of the system is latency-critical and 80% is not. D allows us to quickly finish 80% and really concentrate on the critical 20%. I must also comment upon how much more productive it is to write a new system in D as compared with C++ - gives us more time to think about the actual problem than try to jump through the C++ hoops.

3. A much better type system - some checks can be moved to compile time. Major benefit.

>
>> 2. After much testing, we concluded that fear-of-GC-collects is
>> overblown. Avoid allocating in the main loops as far as possible.
>>
>
> Really? Why is that... because it has no noticeable effect in your system?

Yes. I am commenting about our systems - we disable the GC during critical periods and then go back and collect collect collect later when things calm down. And as such there is minimal allocation in critical sections - we try to ensure all allocation is done beforehand. We followed a similar approach in C++ too since malloc/new is so slow.

>
>> 3. Code is _much_ more maintainable and easier to understand.
>>
>
> I would bet so.
>
>> 4. It's fun to code again - and this point cannot be stressed
>> enough. C++ is a major headache but earlier we had no choice.
>>
>
> Fun is important - especially at an HFT startup. Just imagine the pain endured by new hires at firms with mounds of C++.
>
>> I'm quite confident that D is going to make good inroads into the
>> financial industry in the coming years.
>
> My bet is it will make inroads in finance but more on the infrastructure, web, general programming side and less on the HFT, low-latency side. Probably less on the Quant side as well without something compelling. Julia is compelling with its focus on math and clear benefits over current RAD alternatives numpy, R, Matlab, etc. I don't yet see where D adds distinction to that game yet - other than being a great language.  We'll see.

Yes - R, Matlab et all won't be replaced by D most likely. Let's wait and watch. However I disagree about the HFT/low-latency side. Ofcourse there's no way to say for sure. Let's check again in a year :)

>
> Thanks
> Dan

Saurabh

Am 22.03.2014 14:21, schrieb Daniel Davidson:
> On Saturday, 22 March 2014 at 12:54:11 UTC, Paulo Pinto wrote:
>> Am 22.03.2014 13:38, schrieb Daniel Davidson:
>>> 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.
>>>
>>> Thanks
>>> Dan
>>
>> Maybe this is a wrong conclusion, but from the comments, I would say
>> the Java version is pretty much on par with the C++ attempts.
>>
>
> I guess it depends where your edge comes from. If it is speed, the
> following suggests it is worth it to go C++. 10% is huge and reduction
> in variability is also huge.
>
> [[ So what does this all mean for the Disruptor?  Basically, the latency
> of the Disruptor is about as low as we can get from Java.  It would be
> possible to get a ~10% latency improvement by moving to C++.  I’d expect
> a similar improvement in throughput for C++. The main win with C++ would
> be the control, and therefore, the predictability that comes with it if
> used correctly.  The JVM gives us nice safety features like garbage
> collection in complex applications but we pay a little for that with the
> extra instructions it inserts that can be seen if you get Hotspot to
> dump the assembler instructions it is generating. ]]
>
> If your edge is quickly trying out new algorithms and identifying edge
> by trying many less latency sensitive strategies in the market - then
> "pretty much on par" is a fine bar.
>
> Thanks,
> Dan
>

I read a bit more into it, as the post is from 2011, there are some comments of bringing the performance findings into the following Disruptor's version and the discussion about code generation quality of different Java JIT compilers.

So I would be curious how the 2014 version of Disruptor with modern JVMs like Hotspot, JRockit, Azul fare against the C++ version in modern C++ optimizing compilers like Intel C++, Visual C++.

Going a bit off topic, as although I do like C++, the day job is in JVM/.NET land  where we sometimes do replace C++ systems by the later ones, but I don't possess any trade experience besides what I get to read in blogs and articles.

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?

Asking, because on our enterprise consulting I see most companies willing to sacrifice performance vs salaries, with direct impact on the technology stack being used.

--
Paulo

On Saturday, 22 March 2014 at 13:36:01 UTC, Saurabh Das wrote:
> The edge for D in our case comes from 3 factors -
>
> 1. A lot of statistical data from older C++ systems means better assumptions and decisions in the new D system; and
>

But, clearly that is not necessarily a benefit of D. It is a benefit of prior experience and the learning curve. If you said, we use our data to not only make better assumptions/decisions, but to do things in D that can not be done in C++ - then you make a very strong case.

> 2. 20% of the system is latency-critical and 80% is not. D allows us to quickly finish 80% and really concentrate on the critical 20%. I must also comment upon how much more productive it is to write a new system in D as compared with C++ - gives us more time to think about the actual problem than try to jump through the C++ hoops.
>

Productivity is very important and can mean big $$ for most firms. But if latency is the critical factor in an all-or-nothing game, then it is much less so. Maybe your game is different and you have edge beyond low latency. I hope that is the case.

> 3. A much better type system - some checks can be moved to compile time. Major benefit.
>

What is a simple example of something that could be done with D but not C++ that has nothing to do with building things with less developer time?

For example, I could see technical reasons why in certain non-quant areas like XML parsing where D can be faster than C++. (http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/) But then, with a large amount of time and unlimited funding the techniques could probably be duplicated in C++.

Again, I don't think it is necessary to have any/many cases where D beats C++ hands down in performance for its adoption to widen. But to push D to a wider audience by focusing on areas where the bar is already super high is tough. If I had money to invest in D I would invest it in vibe rather than quant because the relative advantages of D are so much higher.

> Yes - R, Matlab et all won't be replaced by D most likely. Let's wait and watch. However I disagree about the HFT/low-latency side. Ofcourse there's no way to say for sure. Let's check again in a year :)

Sounds good - keep us posted!

Thanks
Dan