總覽

關(guān)于什么是高頻交易的最佳解決方案，存在不同意見(jiàn)。 問(wèn)題的一部分是高頻交易的變化超出您的預(yù)期，另一部分是更快的含義。

我的看法

如果您有一個(gè)典型的Java程序員和一個(gè)典型的C ++程序員，并且每個(gè)人都有幾年編寫典型的面向?qū)ο蟪绦虻慕?jīng)驗(yàn)，并且給了他們相同的時(shí)間，那么Java程序員可能會(huì)更早地?fù)碛幸粋€(gè)工作程序，并且將擁有更多的工作時(shí)間。是時(shí)候調(diào)整應(yīng)用程序了。 在這種情況下，Java應(yīng)用程序可能會(huì)更快。 恕我直言。

以我的經(jīng)驗(yàn)，Java在檢測(cè)不需要執(zhí)行的代碼方面在C ++上表現(xiàn)更好。 esp微型基準(zhǔn)測(cè)試，無(wú)濟(jì)于事。 ;）如果您在不花任何時(shí)間和精力的情況下盡可能地調(diào)優(yōu)Java和C ++，那么C ++程序?qū)⒏臁?但是，在有限的資源和不斷變化的環(huán)境中，動(dòng)態(tài)語(yǔ)言將無(wú)法運(yùn)行。 即在實(shí)際應(yīng)用中。

在股票空間延遲中，您需要將潛伏期定為10到10毫秒以下才能使頻率很高。 不能選擇Java甚至商用硬件上的標(biāo)準(zhǔn)OOP C ++。 您需要C或C ++的精簡(jiǎn)版以及專用硬件，例如FPGA，GPU。

在FX中，高頻意味著延遲小于100 us。 在此空間中，可以選擇使用C ++或帶有內(nèi)核旁路網(wǎng)絡(luò)適配器的精簡(jiǎn)Java（低GC）。 在這種情況下，使用一種或另一種語(yǔ)言將有加有減。 就個(gè)人而言，我認(rèn)為隨著交流的不斷變化，Java會(huì)提供更大的靈活性，前提是您認(rèn)為可以利用IT獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。

在許多情況下，當(dāng)人們談?wù)摳哳l（尤其是Banks）時(shí)，他們說(shuō)的是1 ms以下或一位數(shù)ms。 在這個(gè)領(lǐng)域，我想說(shuō)Java，Scala或C＃等的靈活性/動(dòng)態(tài)編程將給您時(shí)間，與C / C ++或FPGA相比，具有可維護(hù)性和可靠性方面的優(yōu)勢(shì)。


Java面臨的問(wèn)題

問(wèn)題不在于語(yǔ)言本身，而是缺乏對(duì)緩存，上下文切換和中斷的控制。 如果復(fù)制一塊內(nèi)存（發(fā)生在本機(jī)內(nèi)存中，但是在運(yùn)行之間使用了不同的延遲），則該副本會(huì)變慢，具體取決于副本之間發(fā)生的情況。

問(wèn)題不是GC或Java，因?yàn)檫@兩者都不起作用。 問(wèn)題在于緩存的一部分已被換出，副本本身需要更長(zhǎng)的時(shí)間。 這對(duì)于任何訪問(wèn)內(nèi)存的操作都是相同的。 例如訪問(wèn)普通對(duì)象也將變慢。

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); }

測(cè)試多次執(zhí)行相同的操作，執(zhí)行該測(cè)試之間的延遲有所不同。 該測(cè)試將大部分時(shí)間花費(fèi)在本機(jī)方法上，并且沒(méi)有像在測(cè)試期間那樣創(chuàng)建或丟棄任何對(duì)象。

收益率：復(fù)制內(nèi)存延遲1/50/99％tile 1.6 / 1.6 / 2.3 us
NO_WAIT：復(fù)制內(nèi)存延遲1/50/99％tile 1.6 / 1.6 / 1.6 us
BUSY_WAIT_10：復(fù)制內(nèi)存延遲時(shí)間為1/50/99％tile 3.1 / 3.5 / 4.4 us BUSY_WAIT_3：復(fù)制內(nèi)存延遲時(shí)間為1/50/99％tile 2.7 / 3.0 / 4.0 us BUSY_WAIT_1：復(fù)制內(nèi)存延遲時(shí)間為1/50/99％tile 1.6 / 1.6 / 2.6 us SLEEP_10：復(fù)制內(nèi)存延遲時(shí)間為1/50/99％tile 2.3 / 3.7 / 5.2 us SLEEP_3：復(fù)制內(nèi)存延遲時(shí)間為1/50/99％tile 2.7 / 4.4 / 4.8 us SLEEP_1：復(fù)制內(nèi)存延遲時(shí)間為1/50/99％tile 2.8 / 4.6 / 5.0 us

執(zhí)行內(nèi)存復(fù)制所需的典型時(shí)間（中間值）在1.6到4.6 us之間，這取決于是否有1到10毫秒的繁忙等待或睡眠時(shí)間。 這個(gè)比率大約是Java的3倍，但與Java沒(méi)有任何關(guān)系。 甚至最好的時(shí)間也相差約2倍。


編碼

ThreadlatencyTest.java


結(jié)論

在超高頻下，核心引擎將比OOP C ++或Java更多的C，匯編和自定義硬件。 在引擎的延遲要求不太嚴(yán)格的市場(chǎng)中，C ++和Low GC Java成為了選擇。 隨著等待時(shí)間要求變得不那么嚴(yán)格，Java和其他動(dòng)態(tài)語(yǔ)言可能會(huì)變得更有效率。 在這種情況下，Java可以更快地推向市場(chǎng)，因此您可以利用市場(chǎng)/需求變化中的優(yōu)勢(shì)。

參考： C ++或Java，高頻交易更快？ 來(lái)自我們的JCG合作伙伴 Peter Lawrey在Vanilla Java 。

相關(guān)文章：

• Java中的低GC：使用原語(yǔ)而不是包裝器
• Java Lambda語(yǔ)法替代
• JVM如何處理鎖
• Erlang與Java內(nèi)存架構(gòu)
• Java Fork / Join進(jìn)行并行編程
• Java最佳實(shí)踐系列
• 如何在Java中獲得類似于C的性能

翻譯自: https://www.javacodegeeks.com/2011/07/c-or-java-which-is-faster-for-high.html

總結(jié)

以上是生活随笔為你收集整理的C ++或Java，高频交易哪个更快？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。