战术层面来讲量化交易者的核心竞争力在于打造两个高效的平台，回测平台以及执行平台，对于执行平台来说除了精确实现策略思路外最重要的就是执行效率，其中包括滑点控制，很多优秀的策略能否长期生存某种程度来讲相当依赖执行效率，执行效率里面的滑点控制是每一个量化交易者必须解决的难关，毫不夸张地说几乎任何市面上的程序化软件几乎都能实现大部分的复杂策略（价差对冲等除外），再复杂的东西把它切开任何一款程序化软件几乎都能通过组合来实现，不同软件主要分别仍然是执行效率。
对于滑点控制我们首先要清楚构成滑点的三大原因才能对症下药，滑点的产生主要归为三类原因：
1）交易回路--简单说就是委托-柜台-交易所撮合然后回报的整个回路，这个回路涉及几个问题，一是报单环节二是信息通道，高效的报单环节一般指的是从客户端直接报入柜台，有的软件中间强制加入软件上服务器，例如TB，文华等，这里就会产生两个问题，一个是延迟问题，一个是软件商服务器容量和稳定问题，为了迁就服务器容量有的软件商甚至限制一个时间点通过的报单数量，例如文华，严重影响多策略的执行效率，另外我们经常谈的网络速度也属于交易回路里面的问题，例如放在张江机房就是解决网速的问题，很多人以为解决网络问题就基本解决滑点问题其实这远远不够，另外交易柜台的代码和报单效率也属于这个范畴，但柜台的执行效率影响因素不大，现在四大柜台基本上顶尖的是飞马，最次的是CTP，这个话题暂不深入
2）策略代码执行效率，这里分成两部分，一个是代码编写的技巧，二是软件采用的语言，总体来说采用任何一种脚本语言编写代码都是低效的，一些低端的软件例如文华，TB，MC和易盛等用的都是脚本语言，这些语言可以说都是用C来开发的，目的就是为了照顾没有编程基础的用户，牺牲的就是执行效率，一些高端的软件例如MQ等直接用C#开发，当然最好就是各大平台基本都提供API接口提供给交易者自由开发，执行效率高的同时对交易者的编程水平也是一个考验。对于脚本语言很多人其实也是滥用函数导致雪上加霜，例如一些barslast,barsinceentry等函数需要往回追溯，很多人为了方便直接采用这些函数导致策略执行效率大幅降低，另外滥用账户函数，我们知道一般软件提供两种账户函数，策略账户和实际账户，实际账户需要直接访问柜台获取参数，即使采用C 这类高效的语言也不建议频繁访问柜台，但很多人为了方便过度使用账户函数导致代码运行效率太低，一个300毫秒反应速度的策略变成800毫秒，超过一个TICK的时间，不滑点才怪……
3）跳价，跳价问题比较头疼，尤其频繁出现在活跃品种价格大幅度运动，这就需要基于事件驱动基础设计的软件，很多低端的软件都尝试加入事件驱动类函数，实际上根本就是中看不中用，事件驱动型的程序需要建立在高效的代码平台，脚本语言本身效率就地，加上回路限制基本上等你反应过来再采取动作几个TiCK都过去了，事件驱动类的思路通常能部分解决极端行情，核心就是对各种非常规情况用最快速度做出反应，除了代码的编写能力还直接依赖编程者的实盘经验
联系客服
