简化程序执行路径是加快交易最有效途径

“临近”已经成为当今资本市场技术的一个口号。许多企业使其交易算法的托管位置尽可能接近证券交易所——通常位于交易所自己的主机托管中心内。这样做的目的是通过缩短通信距离加快自动化交易的完成。考虑到数据包在光缆中的传播速度，虽然这种做法听起来有些牵强，但是也充分说明当今买卖交易的时间尺度以及从交易周期中节省几微秒也是一种竞争优势。

然而，我们很少听到人们讨论交易中会导致延迟的另一种距离：执行路径，即执行某项任务CPU必须完成的一系列指令的长度。与上面例子中的物理距离类似，CPU指令产生的时间开销看起来微乎其微。因为处理器速度通常以每秒执行数十亿条指令来衡量。

效果优于主机托管

但是自动化交易和其他实时资本市场功能都具有计算密集型的特点，它们可能需要执行数百万甚至数十亿条指令。而且，与物理距离相比，执行路径具有无可比拟的可塑性。一旦您对系统实施了主机托管，将无法进一步缩短物理距离，而且与同样采用主机托管的其他竞争对手相比，您没有任何优势可言。然而，通过多种对软件的更改，从微调代码(如果在循环函数中重复数千次，算法中使用switch/case和if/then/else语句的效率差距可能会开始显现)到完全重新设计系统和应用程序可能会带来大幅效率提升。

短执行路径的另一个优势是，可以提高在CPU需要代码段时其位于一级/二级缓存的几率。如果系统遇到的指令没有位于缓存中，则必须从主内存检索指令，因此可能会形成性能瓶颈。例如，在配备2.4 GHz CPU和400 MHz前端总线的系统中，从内存取指令相当于在240千米/小时的高速公路上为了躲避障碍物将速度降低到40千米/小时，然后再以240千米/小时的速度驶向下一个障碍物。

要理解实时金融市场具有的计算密集型特点，请考虑算法交易系统中的风险管理功能。下订单时，会执行相关代码，确定是否允许交易。风险管理算法会对海量信息进行排序和筛选，获得所需的数据点并且应用复杂的数学运算来评估数十个参数的风险。由于在交易完成前必须进行风险评估，因此对风险管理代码有严格的时间要求;而且由于交易所不断扩展的数据广播服务等因素，实现其目标必须处理的数据量也在不断增长。

再举一个例子，比如某个公司的目标是缩短风险管理延迟，以便将订单处理时间缩短至不到1毫秒。硬件每秒可以处理100亿条指令(不考虑会影响延迟的其他因素)，1毫秒的限制表明订单处理的最大允许执行路径是执行1,000万条指令。假如通过巧妙地编程，该公司提高了软件效率，使订单处理延迟比该限制缩短了35%，换句话说，处理时间降低了350微秒(或者在相同时间可以多处理350万条指令)。

这相当于将主机托管距离缩短了多少?光缆中的数据包以光速传播，受光缆折射率的影响传播速度会略小一些，根据经验该速度通常可以达到124,274英里/秒。按照该速度(并且假设所有其他因素都相同)，35%的代码效率提高相当于将物理距离缩短了43英里，远远超过了促使公司考虑采用主机托管的最短距离25英里。

结果可能有所不同

35%的效率提高并不是来自对所有应用程序的调整甚至重新设计。但是，在采用其他技术领域的新方法后，通常确实可以获得这种效率提高。例如，资本市场的开发人员已经成功借鉴了嵌入式系统领域的经验，例如实时航空航天和电信系统等。嵌入式技术之所以吸引金融系统的开发人员，是因为它具有快速(设想如果喷气式飞机的航空电子系统速度不够迅速会造成怎样的后果)、确定性(可预测的响应时间)以及容错等特点。嵌入式开发人员长期关注于(有时非常着迷)缩短执行路径以便最大限度地降低CPU利用率，在获得所需性能的同时，允许嵌入式系统使用功能不是非常强大的处理器。

将嵌入式系统的理念转移到金融技术中的一个例子是数据库系统，尤其是开发人员使用的应用程序编程接口(API)从应用程序节点调用数据库的函数。通常来说，如果嵌入式软件的开发人员使用即用型数据库系统，他们会选择具有引导性的本机语言API的系统，也就是说，它由嵌入到应用程序代码的函数组成，并且通过物理数据结构一次处理一条记录，利用应用程序逻辑决定当前记录行是否属于目标集合。

这种方法与企业应用程序(包括许多金融系统)中广泛使用的SQL API形成了鲜明的对比。SQL能够为程序员提供更高层次的抽象，这样可以带来更多便利，但付出的代价是更长的执行路径。在SQL操作接触物理数据之前，命令(SQL语句)需要经过解析和优化过程。而后者尤其需要占用大量CPU资源，其中优化器逻辑将检查多种执行操作的方式，以确定最高效的途径。

由于本机API的执行路径通常较短，而SQL的执行路径较长，因此这两种API的性能差异非常显著。为了演示SQL与本机API的性能对比，我们利用托管在SGI Altrix 4700系统，采用80枚双核1.6 Ghz英特尔安腾2处理器(总计160个核心)和4 TB NUMA RAM，运行SUSE Enterprise Linux 9的内存数据库(IMDS)上对相同的数据(存储在主内存中，包含三个表，1.17 TB，155亿行的数据库)执行了相同的查询。

在执行最简答的查询过程中，采用SQL API的数据库系统每秒可以完成2,821万次“SELECT” 操作。在采用本机、引导性API实现的相同查询中，每秒可以完成8,778万次查询。在需要三表联接的更复杂操作中，SQL API每秒完成了436万次查询，而本机API每秒完成了1,113万次查询。金融系统的开发人员越来越多地寻找后一种类型的接口并且通过使用它实现更高的性能。

执行路径已经成为与物理距离一样可以降低延迟的途径。为了满足低延迟资本市场的竞争挑战，交易公司需要从这两个方面同时着手。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。