Walter's DConf 2014 Talks - Topics in Finance

[Paulo Pinto]

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