Walter's DConf 2014 Talks - Topics in Finance

Saurabh Das saurabh.das at gmail.com
Sat Mar 22 06:35:59 PDT 2014


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


More information about the Digitalmars-d mailing list