低延迟系统请选择Java而不是C++ - stackoverflow

21-03-06 banq

在开发低延迟的软件系统时,人们普遍认为,除了C ++之外,您使用其他任何语言是疯狂的,因为其他任何语言都具有很高的延迟。但是,我在这里是要说服您使用相反的、违反直觉的、几乎是异端的概念:在软件系统中实现低延迟时,Java更好。

在本文中,我想以一个特殊的软件示例为例,该软件具有低延迟性。交易系统。但是,我在这里所做的论点几乎可以应用于需要或希望有低延迟的任何情况。只是相对于我有经验的开发领域而言,讨论起来更加容易。事实是,延迟可能很难衡量。

这一切都取决于您对“低延迟”的定义。让我解释…

 

接受的智慧

让我们先来看一下为什么您应该选择C ++来构建高速,低延迟的系统的原因。 

由于C ++更接近基本知识,因此大多数开发人员都会告诉您,使用该语言进行编码具有固有的速度优势。在低延迟情况下(例如高速交易),微秒可以使可行的软件与过时的磁盘空间浪费有所不同,C ++被视为黄金标准。

或者至少曾经是。现实是,如今,许多大型银行和经纪人都使用Java编写的系统。

C ++在执行代码时可能是“低延迟”,但是在推出新功能甚至寻找可以编写它的开发人员时,绝对不是低延迟。 

 

Java和C ++之间的(实际)区别

关于开发环境中的Java和C ++之间的真正差异,这仅仅是开发时间的开始。因此,为了了解每种语言在这种情况下的真正价值,让我们对其进行一些整理。

首先,重要的是要记住在大多数情况下C ++比Java更快的实际原因:C ++指针是内存中变量的地址。这意味着软件可以直接访问各个变量,而无需遍历计算量大的表来查找它们。或者至少可以告诉他们它们在哪里,因为使用C ++,您通常必须显式地管理对象的生存期和所有权。 

这样的结果是,除非您真的非常擅长编写它(一项技能可能需要数十年才能掌握),否则C ++将需要数小时(或数周)的调试时间。而且,正如任何尝试调试Monte Carlo引擎或PDE求解器的人都会告诉您的那样,尝试在基本级别上调试内存访问可能会非常耗时。仅仅一个坏了的指针就很容易使整个系统崩溃,因此交付用C ++编写的新版本确实很恐怖。

当然,这还不是全部。那些喜欢用C ++编程的人(所有这三个人)都会指出Java中的垃圾收集器(GC)遭受非线性延迟尖峰的困扰。使用旧版系统时尤其如此,因此在不破坏客户系统的情况下向Java代码交付更新可能会使它们变得如此缓慢以致无法使用。

对此,我要指出,为减少Java GC在过去十年中产生的延迟,已经做了很多工作。例如,LMAX Disruptor是一个用Java编写的低延迟交易平台,但也被构建为一个框架,该框架对其运行的硬件具有“机械同情”,并且是无锁的。 

如果您要构建使用持续集成和交付(CI / CD)流程的系统,则可以进一步缓解问题,因为CI / CD允许自动部署经过测试的代码更改。这是因为CI / CD提供了一种迭代的方法来提高GC延迟,在这种方法中,可以逐步改进Java并针对特定的硬件环境进行Java定制,而无需花费大量资源就可以在交付之前为不同的硬件规格准备代码。 

由于IDE对Java的支持比对C ++的支持要先进得多,因此大多数环境(Eclipse,IntelliJ,IDEA)都可以重构Java。这意味着大多数IDE将允许您优化代码以使其以低延迟运行,而该功能在使用C ++时仍然受到限制。 

即使在原始性能上与C ++不完全匹配,大多数开发人员也将比在C ++中更容易在Java中达到可接受的性能。真正的延迟杀手是介于有想法和发布代码之间。 

 

我们所说的更快是什么意思?

实际上,有充分的理由质疑C ++确实比Java真正“更快”或“更低的延迟”。在这一点上,我知道我进入了一些暗淡的水域,并且许多开发人员可能开始质疑我的理智。但是,请听我说。

首先,有一点(有点荒谬):如果您有两个开发人员,一个是用C ++编写的,另一个是用Java编写的,并且您要求他们从头开始编写一个用于高速交易的平台:在数组边界之外建立索引在Java和C ++中都是错误。如果您不小心在C ++中执行了此操作,则可能会出现段错误,或者(更常见的是)您会得到一些随机数,即使对于有经验的开发人员也不会有任何意义。在Java中,索引越界总是抛出ArrayIndexOutOfBoundsException。这意味着在Java中调试非常容易,因为错误往往会立即引发错误,并且更容易跟踪错误的位置。  

此外,至少就我的经验而言,Java(在大多数环境中)仅擅长识别哪些代码段不需要运行以及哪些代码对您的软件正常运行至关重要。当然,您可以花几天时间调整C ++代码,使其绝对不包含多余的代码,但是在现实世界中,每个软件都包含一些膨胀,而Java更擅长自动识别它。

这意味着,在现实世界中,即使在标准的延迟度量上,Java的速度通常也比C ++快。即使不是这样,语言之间的延迟差异也常常被其他因素淹没,甚至在高频交易中也相差甚远。例如,很多研究表明5G网络的等待时间减少了(据一些分析家称降至1ms),但是在低等待时间编程中,这仍然代表了巨大的性能成本。 

 

Java在低延迟系统中的优势

在我看来,所有这些因素都构成了使用Java编写高速交易平台(实际上,实际上是低延迟系统,不久之后还会有更多内容)的一个无懈可击的案例。 

但是,只是为了让C ++发烧友多一点,让我们看一下使用Java的许多其他原因:

  • 首先,正如我们已经在上面看到的那样,Java引入您的软件的任何额外延迟都可能比(至少)在一个必须交易的系统中必须存在的现有延迟接收器(例如网络通信延迟)小得多。通过之前完成。这意味着在大多数交易情况下,任何(编写良好的)Java代码都可以轻松实现与C ++一样好的性能。
  • Java开发时间的缩短还意味着,在现实世界中,用Java编写的软件比C ++可以更迅速地适应变化的硬件(甚至是新颖的交易策略)。
  • 进一步了解这一点,您会发现,即使从整个软件的角度来看,优化Java软件也比C ++中的等效任务更快。正如对低延迟和整个系统的高效率感兴趣的Java顾问Peter Lawrey最近对InfoQ所说: “如果您的应用程序将90%的时间花费在10%的代码中,则Java会使优化工作的难度提高10%,但编写并维护90%您的代码百分比更容易;特别是对于混合能力的团队。”

 在Java中,调试,敏捷开发以及对多种环境的适应都变得更加简单快捷。

  

关于如何实现低延迟的争论并不是一个新话题,而且对于金融界而言并非唯一。因此,可以从中学习有关其他情况的宝贵经验。特别是,上面的论点-Java更“好”,因为它更灵活,更具弹性,并且最终可以更快地开发和维护-可以应用于软件开发的许多领域。

我(个人)更喜欢用Java编写低延迟系统的原因与过去25年来使该语言取得如此成功的原因相同。Java易于编写,编译,调试和学习,这意味着您可以花更少的时间编写代码,而将更多的时间用于优化延迟。最终,在现实世界中,这将导致可靠的更快的交易系统。而且,对于高速交易而言,这才是最重要的。

 

                   

猜你喜欢