似乎所有主要的投资银行在Unix（Linux，Solaris）中都使用C ++来实现低延迟/高频率的服务器应用程序。 为什么Windows通常不会被用作这个平台？ Windows不能竞争的技术原因是什么？
用于算法交易的极低延迟系统的性能要求是极端的 。 在这个环境中，微秒数。
我不确定Solaris，但是Linux的情况下，这些人正在为整个内核编写和使用低延迟补丁和自定义，从网卡驱动程序开始。 这并不是说为什么在Windows上无法做到这一点，而是有一个实际/合法的原因 – 访问源代码，以及用更改重新编译的能力。
从技术上讲，不。 然而，有一个非常简单的商业原因：其余的金融世界运行在Unix上。 在AIX上运行的银行，股票市场本身运行在Unix上，因此，在金融领域找到用于Unix环境而非Windows环境的程序员就简单多了。
（我在投资银行工作了8年）事实上，很多银行称之为低延迟的工作都是在Java中完成的。 甚至没有实时Java – 关闭GC就是普通的Java。 这里的主要技巧是确保你已经完成了所有的代码，让jit在你将某个特定的虚拟机转换为prod之前已经运行（所以你有一些启动循环运行了几分钟 – 和热故障转移） 。
使用Linux的原因是：
熟悉
远程管理仍然更好，影响也较小 – 对机器上其他进程的影响最小。 请记住，这些系统通常位于交换机上，因此与机器（从您/您的支持团队）的链接可能会比您正常的数据中心更差。
调优 – 将swappiness设置为0，让JVM预分配大页面的能力，以及其他低级技巧是非常有用的。
我相信你可以让Windows工作的可以接受，但是这样做没有什么大的优势 – 正如其他人所说的那样，你所雇用的任何员工都不得不重新发现他们所有的延迟破坏技巧，而不仅仅是一个核对清单。
原因很简单，10 – 20年前当这样的系统出现时，“核心”多CPU服务器只能在某种UNIX上运行。 Windows NT最近在仁慈的花园里。 所以理由是“历史的”。
现代系统可能在Windows上开发，这只是近来的一个问题。
PS：我正在这样的系统之一currencly工作:-)
Linux / UNIX更适用于并发远程用户，这样可以更容易地在系统上编写脚本，在日志上使用像grep / sed / awk / perl / ruby / less这样的标准工具… ssh / scp …所有这些东西就在那里。
还有一些技术问题，例如：在Windows上测量已用时间，您可以在基于Windows时钟滴答的一组函数和基于硬件的QueryPerformanceCounter（）之间进行选择。 前者是每10到16毫秒递增一次（注意：一些文档意味着更高的精度 – 例如GetSystemTimeAsFileTime（）的值可以测量到100ns，但是它们报告的是同一个100ns的时钟边沿，直到再次滴答）。 后者 – QueryPerformanceCounter（） – 在不同的核心/ cpus可以报告自启动以来由于在系统引导过程中的不同时间预热而相差几秒钟的情况下显示停止问题。 MSDN将此文档记录为可能的BIOS错误，但这很常见。 那么，谁想要在一个无法正确安装的平台上开发低延迟的交易系统呢？ （有解决方案，但你不会找到任何软件坐在boost或ACE方便）。
许多Linux / UNIX版本都有很多简单易用的参数，可以根据负载的平均延迟，时间片大小，调度策略等来平衡单个事件的延迟。在开放源代码操作系统上，还可以保证能够当你认为某事应该比现在更快，并且知道一个（可能是巨大的）人群已经并且正在严格地这么做的时候 – 在Windows中，显然主要是被分配到的人看它。
在FUD /声誉方面 – 有些无形但是选择操作系统的重要原因 – 我认为业内大多数程序员只会更信任Linux / UNIX来提供可靠的调度和行为。 此外，尽管Windows现在非常可靠，但Linux / UNIX的崩溃声名远播，而Linux的代码基础比Solaris或FreeBSD更为灵活。
有多种原因，但其原因不仅是历史的。 事实上，似乎现在越来越多的服务器端金融应用程序在* nix上运行（包括从.NET平台切换到伦敦证券交易所这样的大公司）。 对于客户端或桌面应用程序来说，定位除Windows以外的任何东西都是愚蠢的，因为这是已建立的平台。 但是，对于服务器端应用程序，大部分我曾经部署到* nix的地方。
我部分同意上面的大部分答案。 尽管我已经意识到使用C ++的最大原因是因为它拥有非常庞大的STL库，所以速度相对较快。
除此之外，linux / unix系统也被用来提升性能。 我知道许多低延迟的团队，这些团队在一定程度上调整了linux内核。 显然，这种自由度不是由窗口提供的。
其他原因，如遗留系统，许可证成本，资源计数也是较少的驱动因素。 正如“rjw”提到的，我看到团队使用Java以及修改的JVM。
我第二个观点是对历史和访问内核的操纵。
除了这些原因之外，我还认为，就像在一些低延迟的情况下使用这些技术时，它们如何关闭.NET的垃圾回收以及Java中的类似机制。 他们可能会避免使用Windows，因为API的高层与低级别的操作系统以及内核进行交互。
所以核心当然是可以使用低级别os进行交互的内核。 提供高级API仅仅是为了使普通用户的生活更轻松。 但是，在低延迟的情况下，这是每个操作周围的脂肪层和分数秒丢失。 因此，每次通话只需几分钟即可获得一个有利的选择。
除此之外，要考虑的另一件事是整合。 大多数服务器，数据中心，交换机都使用UNIX而不是Windows，所以使用同一个家族的客户端使得集成和通信更容易。
然后你有安全问题（很多人可能不同意这一点虽然）与黑客WINDOWS相比，黑客入侵并不容易。 我不同意银行的授权是银行面临的问题，因为他们在硬件和软件的每一块钱上花钱，还有那些定制他们的人，所以购买许可证在考虑购买时可能不会那么大。