Windows和Mac OS X IO的差异，2015年的性能调整？

Question

经验丰富的Mac / OS X Developer，使用libCinder，一个用于图形的跨平台C ++工具包，寻找有关优化Windows磁盘访问的一些指导。

我正在优化磁盘访问以读取（大型，高分辨率）图像序列。我在运行OS X 10.10的Mac上实现了我的优化，并且我的磁盘性能几乎翻了两番，以匹配合成磁盘基准测试（yay）。

在Windows上测试相同的代码会导致性能不提高（嘘！）

我想解释一下我在做什么，为什么，以及我理解的东西。

我的代码的当前状态：

我的代码有4个主题：

• 主线程向上移动OpenGL和Renders，处理事件等。
• 线程1从磁盘读取并将我的图像从其磁盘表示（tiff header和all）直接加载到内存中，并转储到cinder缓冲区对象的并发循环缓冲区中。 （监制）。
• 线程2从缓冲区（Consumer）的循环缓冲区中读取并将它们“解码”为原始煤渣表面对象（未压缩的图像数据），并将它们添加到第二个表面的并发循环缓冲区（生产者）
• 线程3从我的Surface缓冲区读取并作为纹理提交到辅助GL上下文，并通知主要有可用的新纹理。

我通过这种方式将我的线程与测量性能和热点分开，表明磁盘访问+文件解码是一个限制因素，通过解耦它们我能够获得收益。

现在，在磁盘读取的线程1中，我尝试了几种不同的磁盘访问方法：

• 通过ci :: DataSourcePath
使用库提供的磁盘访问（Mac + Win）
• fread（Mac + Win），
• CreateFile（Win Only）
• mmap（目前仅限Mac）

在OS X上，我看到使用fread（没有缓存和通过fcntl的预读标志）导致使用Cinder提供的ci :: DataSourcePath对象稍微好一点的持续磁盘读取性能，但不是很多。我几乎可以通过这两种方法使我的Mac Book Pro的SSD读数大致达到750MB / s。有趣的是内存映射文件访问（使用madvise）并不是那么快（400-500MB / s），但这就是我们基准测试的原因。

在Windows上，CreateFile，fread（没有我没有知道缓存的标志）和ci :: DataSourcePath都会产生类似的性能，但是，它的200MB / s，在我的硬件上应该可以接近8GB / s（是的，严重的是，我们已经搜查了英特尔PCI固态硬盘）。

那很惨！

对于比Windows磁盘IO更熟悉的人的一些问题：

• 研究表明Windows CreateFile的FILE_FLAG_NO_BUFFER + FILE_FLAG_OVERLAPPED是（是？）的方法。
• 其他信息表明我应该使用IOCompletionPorts和async IO。
• Boost :: ASIO是否可用于高性能，无缓冲的磁盘访问？大多数帖子表明它被用于套接字。

我想避免过多的跨平台复杂性（重叠和异步IO似乎非常重要），而且我觉得完全相同的x64架构会导致如此截然不同的性能。我错过了什么 - 为什么我的解耦在Windows上工作？我应该在2015年使用什么API？

非常感谢任何建议。

TL; DR - 经验丰富的Mac开发人员尝试对跨平台磁盘IO进行一些基本优化，但在Windows上失败，Windows IO很奇怪，我应该在2015年使用什么API来获取Windows上的快速磁盘读取？

感谢。