ZZ C++还是Java 哪个响应高频交易应用比较快

摘要：高频交易是指从那些人们无法利用的极为短暂的市场变化中寻求获利的计算机化交易，这种交易的最大特点就是速度非常快，以至于有些交易机构将自己的“服务器群组”（server farms）安置到了离交易所的计算机很近的地方，以缩短交易指令通过光缆以光速旅行的距离。
概述

高频交易的最佳解决方案是什么？对于这个问题，观点一直比较冲突，部分原因是人们不知道什么叫高频交易并且与人们想象的总是存在差异，其次是速度问题，用哪种语言开发速度会快点，本文作者拿当今非常流行的C++和Java这两种语言进行比较。

如果你是一个典型的Java和C++程序员，并且用这两种语言编写过典型的面向对象程序。在相同的时间下面编写高频解决方案，Java程序员有可能会提前完成程序并且有时间调整应用程序。在这种情形下，恕我直言，Java应用程序的速度会快些。

以我的经验，Java在执行上会好于C++，因为Java无需检查代码，尤其是微基准测试，其实它没有做什么事情。但是如果没有时间限制，对Java和C++程序进行调优，那么C++程序会快些。然而，考虑到有限的资源和不断变化的环境，一个充满活力语言可能会超常发挥，即在现实世界中应用。

在股票交易这种高频市场，即使延迟10微秒都需要认真对待。 Java甚至标准的OOP C++，用在商业硬件上都不是最佳选择，你需要借助C或者精简版的C++和一些专业的硬件工具，例如FPGAs、GPUs。
. check 1point3acres for more.
然而，在外汇（FX：Foreign Exchange）市场，高频意味着延迟时间不低于100微秒。在这个的环境下，C++或者精简版的Java（低GC）内核绕过网络适配器是一个不错选择。个人认为，在不断变化的交易场所，Java拥有更多的灵活性。

当人们讨论高频率时，尤其是在做银行系统的时候，他们想把时间缩短1毫秒或者单单几毫秒。在这样的情况下，我会说，灵活/多态的Java、Scala或者C#等语言在编程时间上将会更加充裕，可维护性或可靠性优势将会超过C/C++或FPGA。

Java所面临的问题

问题不在于这样的语言上，而是缺乏缓存控制和上下文交互。如果你复制一块在本地已经操作过的内存，但是在运行之间使用不同的延迟，副本将会变慢。

原因是部分缓存被交换出去和复制本身需要更长的时间。这和访问内存的任何操作是一样的。例如，访问计划对象将会更慢。

private void doTest(Pauser delay) throws InterruptedException {  
    int[] times = new int[1000 * 1000];  
    byte[] bytes = new byte[32* 1024];  
    byte[] bytes2 = new byte[32 * 1024];  
    long end = System.nanoTime() + (long) 5e9;  
    int i;  
    for (i = 0; i < times.length; i++) {  
        long start = System.nanoTime();  
        System.arraycopy(bytes, 0, bytes2, 0, bytes.length);  
        long time = System.nanoTime() - start;  
        times[i] = (int) time;  
        delay.pause();  
        if (start > end) break;  
    }  
    Arrays.sort(times, 0, i);  
    System.out.printf(delay + ": Copy memory latency 1/50/99%%tile %.1f/%.1f/%.1f us%n",  
            times[i / 100] / 1e3,  
            times[i / 2] / 1e3,  
            times[i - i / 100 - 1] / 1e3  
    );  
}
这个测试其实是在多次执行同一件任务，在执行之间使用不同的延时。其中大部分时间都花在本地方法上，在测试期间没有创建或抛弃对象。

YIELD: Copy memory latency 1/50/99%tile 1.6/1.6/2.3 us  
NO_WAIT: Copy memory latency 1/50/99%tile 1.6/1.6/1.6 us  
BUSY_WAIT_10: Copy memory latency 1/50/99%tile 2.8/3.5/4.4 us  
BUSY_WAIT_3: Copy memory latency 1/50/99%tile 2.7/3.0/4.0 us  
BUSY_WAIT_1: Copy memory latency 1/50/99%tile 1.6/1.6/2.5 us  
SLEEP_10: Copy memory latency 1/50/99%tile 2.2/3.4/5.1 us  
SLEEP_3: Copy memory latency 1/50/99%tile 2.2/3.4/4.4 us  
SLEEP_1: Copy memory latency 1/50/99%tile 1.8/3.4/4.2 us
-XX+Java 7的UseLargePages

YIELD: Copy memory latency 1/50/99%tile 1.6/1.6/2.7 us  
NO_WAIT: Copy memory latency 1/50/99%tile 1.6/1.6/1.8 us  
BUSY_WAIT_10: Copy memory latency 1/50/99%tile 2.7/3.6/6.6 us  
BUSY_WAIT_3: Copy memory latency 1/50/99%tile 2.7/2.8/5.0 us  
BUSY_WAIT_1: Copy memory latency 1/50/99%tile 1.7/1.8/2.6 us  
SLEEP_10: Copy memory latency 1/50/99%tile 2.4/4.0/5.2 us  
SLEEP_3: Copy memory latency 1/50/99%tile 2.3/3.9/4.8 us  
SLEEP_1: Copy memory latency 1/50/99%tile 2.1/3.3/3.7 us
上面是最好的三种运行。

进行内存拷贝的典型时间（中间值）是1.6到4.6微秒，依据是否有线程在繁忙等待或休眠状态上使用了1到10毫秒。这大概是3倍的比率，并且与Java无关，这是因为它没有真正的控制权。即使在最好的情况下时间差大概也是2倍。

代码

ThreadlatencyTest.java

总结

在超高频率下，核心引擎将会超过C，组装和自定义的硬件可能会比面向对象的C++或Java更快。在市场对延迟要求不太高的前提下，C++和低GC的Java是不错的选择。由于延迟需求越来越不太重要，Java和其他动态语言会更富有成效。在这种情形下，选择Java就可以轻松帮你应对不断变化的市场/需求。

来自：DZone

FPGA都整出来了。。。越走越偏激，早晚HFT要被政府阉割掉。

java性能还是不错的。交易系统其实最大的性能瓶颈是在网络部分，其次是读写文件或数据库。语言本身是性能问题，除非有非常复杂的逻辑计算一般可以忽略不计。

The prop shops in China are using Python to establish the infrastructure... is it the case in the US?