我很好奇F＃性能与C ++性能相比如何？我问了一个关于Java的类似问题，我得到的印象是Java不适合进行大量数字运算。
我已经读到F＃应该具有更高的可扩展性和更高的性能，但是与C ++相比，这种实际性能如何？有关当前实施的具体问题是：
谢谢
Answers:
我很好奇F＃性能与C ++性能相比如何？
视应用而异。如果您在多线程程序中广泛使用复杂的数据结构，则F＃可能是一个大赢家。如果您大部分时间都花在紧密的数字循环变异数组上，那么C ++的速度可能要快2-3倍。
案例研究：射线跟踪器我的基准测试在这里使用一棵树进行分层剔除和数字射线-球面交集代码以生成输出图像。该基准已有数年历史，多年来，C ++代码已进行了数十次改进，并被成千上万的人阅读。Microsoft的Don Syme设法编写了一个F＃实现，该实现比用MSVC编译并使用OpenMP并行化时最快的C ++代码快。
我已经读到F＃应该具有更高的可扩展性和更高的性能，但是与C ++相比，这种实际性能如何？
用F＃开发代码比使用C ++更加容易和快捷，这适用于优化和维护。因此，当您开始优化程序时，如果使用F＃而不是C ++，则相同的工作量将获得更大的性能提升。但是，F＃是高级语言，因此，对性能的限制较低。因此，从理论上讲，如果您有无限时间花在优化上，那么您应该总是能够用C ++生成更快的代码。
当然，这与C ++优于Fortran和Fortran优于手写汇编程序具有相同的好处。
案例研究：QR分解这是LAPACK之类的库提供的线性代数的基本数值方法。参考的LAPACK实现是Fortran的2,077行。我用不到80行代码编写了一个F＃实现，可以实现相同的性能水平。但是参考实现并不很快：像英特尔的数学内核库（MKL）这样的厂商调整的实现通常快10倍。值得注意的是，我设法很好地优化了F＃代码超越使其性能了在英特尔硬件上运行的英特尔实施性能，同时将我的代码保持在150行以下的代码中，并且代码完全通用（它可以处理单精度和双精度，复杂甚至符号矩阵！）：对于较高的薄矩阵，我的F＃代码比Intel MKL快3倍。
请注意，此案例研究的目的并不是要让您的F＃比供应商调整的库更快，而是，即使是像Intel这样的专家，如果他们仅使用低级语言也将错过有效的高级优化。我怀疑英特尔的数值优化专家未能充分利用并行性，因为他们的工具非常繁琐，而F＃使其毫不费力。
浮点运算的效果如何？
性能类似于ANSI C，但是.NET无法使用某些功能（例如，舍入模式）。
它允许矢量指令吗
没有。
对优化编译器有多友好？
这个问题没有道理：F＃是Microsoft专有的.NET语言，带有单个编译器。
它有多少内存占用空间？
一个空的应用程序在这里使用1.3Mb。
是否允许对内存局部性进行细粒度控制？
比大多数内存安全语言要好，但不如C语言好。例如，您可以通过将F＃中的任意数据结构表示为“结构”来拆箱。
它是否具有用于分布式存储处理器（例如Cray）的容量？
取决于您所说的“能力”。如果可以在该Cray上运行.NET，则可以使用F＃传递消息（就像下一种语言一样），但是F＃主要用于台式机多核x86计算机。
在涉及大量处理的计算科学中，它具有哪些有趣的功能？
内存安全性意味着您不会遇到分段错误和访问冲突。.NET 4对并行性的支持很好。通过Visual Studio 2010中的F＃交互式会话即时执行代码的功能对于交互式技术计算非常有用。
是否有使用它的实际科学计算实现？
我们的商业产品在F＃中用于科学计算的已经有数百个用户。
但是，您的疑问线表明您将科学计算视为高性能计算（例如Cray），而不是交互式技术计算（例如MATLAB，Mathematica）。F＃用于后者。
除了其他人所说的，F＃还有一个重要的观点，那就是并行性。普通的F＃代码的性能由CLR决定，尽管您可以使用F＃中的LAPACK，也可以使用C ++ / CLI作为项目的一部分进行本地调用。
但是，设计良好的功能程序往往更容易并行化，这意味着您可以使用多核CPU轻松获得性能，如果您正在进行科学计算，那么这些绝对是可用的。以下是几个相关链接：
关于分布式计算，您可以使用任何适用于.NET平台的分布式计算框架。有一个MPI.NET项目，可以与F＃很好地配合使用，但您也可以使用MSR项目DryadLINQ。
与所有语言/性能比较一样，您的工作量很大程度上取决于您的编码水平。
F＃是OCaml的派生词。我惊讶地发现，OCaml在金融世界中被大量使用，而数字处理性能非常重要。我惊讶地发现OCaml是最快的语言之一，其性能与最快的C和C ++编译器相当。
F＃建立在CLR之上。在CLR中，代码以字节代码的形式表示，称为通用中间语言。这样，如果代码编写得当，它将受益于JIT的优化功能，并且具有与C＃（但不一定是C ++）相当的性能。
使用本机映像生成器（NGEN），可以在运行之前在单独的步骤中将CIL代码编译为本机代码。由于不再需要CIL到本机的编译，因此可以加快软件的所有后续运行速度。
需要考虑的一件事是，像F＃这样的功能语言受益于更具声明性的编程风格。从某种意义上说，您在命令式语言（例如C ++）中过度指定了解决方案，这限制了编译器的优化能力。从理论上讲，更具声明性的编程风格可以为编译器提供更多的算法优化机会。
这取决于您正在执行哪种科学计算。
如果要进行traditional heavy computing线性代数，各种优化等操作，则不应将代码放在.Net框架中，至少不适合F＃。因为这是在算法级别，所以大多数算法必须使用命令式语言进行编码，以在运行时间和内存使用方面具有良好的性能。其他人提到并行，我必须说，当您做诸如并行SVD实现之类的低级工作时，它可能没用。因为当您知道如何并行处理SVD时，您根本不会使用高级语言，Fortran，C或修改的C（例如cilk）是您的朋友。
但是，当今许多科学计算都不是这种类型，它是某种高级应用程序，例如统计计算和数据挖掘。在这些任务中，除了一些线性代数或优化之外，还存在大量数据流，IO，预设，制作图形等。对于这些任务，F＃确实功能强大，因为其简洁，功能，安全，易于操作。并行等
正如其他人提到的那样，.Net很好地支持Platform Invoke，实际上MS中的许多项目都一起使用.Net和P / Invoke来改善瓶颈性能。
不幸的是，我认为您不会找到很多可靠的信息。F＃仍然是一种非常新的语言，因此，即使它非常适合于性能繁重的工作负载，仍然不会有很多具有丰富经验的人来报告。此外，很难准确地评估性能，并且很难概括微基准。即使在C ++中，您也可以看到编译器之间的巨大差异-您是否想知道F＃是否可以与任何其他产品竞争？C ++编译器或假设的“最佳” C ++可执行文件？
至于针对C ++的特定基准，以下是一些可能相关的链接：O'Caml与F＃：QR分解；F＃与非托管C ++的并行数字。请注意，作为F＃相关材料的作者和F＃工具的供应商，作者对F＃的成功有着既定的兴趣，因此请一these而就。
我认为可以肯定地说，在某些应用程序中F＃在执行时间上具有竞争力，而在另一些应用程序中则没有。在大多数情况下，F＃可能需要更多的内存。当然，最终的性能也将高度依赖于程序员的技能-我认为F＃几乎可以肯定是一种对中等能力的程序员来说更具生产力的语言。此外，我认为目前Windows上的CLR在大多数操作系统上的性能要比Mono更好，这可能也会影响您的决定。当然，由于F＃可能比C ++更易于并行化，因此它也取决于您计划在其上运行的硬件类型。
最终，我认为真正回答这个问题的唯一方法是编写代表您要执行的计算类型的F＃和C ++代码并进行比较。
let f x y = (expensive x |> g) y根本不同let f x = expensive x |> g。
这是我可以分享的两个示例：
矩阵乘法：我有一篇博客文章比较了不同的矩阵乘法实现。
轻量级
我有一个使用LBFGS优化的大规模Logistic回归求解器，它是用C ++编码的。该实现进行了很好的调整。我修改了一些代码以C ++ / CLI进行编码，即，将代码编译为.Net。.Net版本比在不同数据集上天真的编译版本慢3至5倍。如果用F＃编码LBFGS，则性能不能比C ++ / CLI或C＃更好（但是会非常接近）。
我还有一篇关于为什么F＃是用于数据挖掘的语言的文章，尽管与您在这里关注的性能问题不太相关，但与F＃中的科学计算非常相关。
inlineF＃的主要好处不是消除了函数调用的开销，而是使CLR对您的代码进行了类型专用化。如果您的LBFGS仅用于处理float array或vector输入和输出，则您针对一种特殊情况手工键入了专用字，这使它的用处大大降低。通用BFGS实现应使用用户提供的功能读取其输入并将其输出直接写入用户的数据结构中。F＃在这里比C＃具有巨大的性能优势。
如果我说“在2-3年后再问”，我认为这将完全回答您的问题:-)
首先，除非您是故意进行一些复杂的递归，而且我猜您自从询问数字以来就没有这种感觉，否则不要指望F＃与C＃性能有任何区别。
由于CLR并非针对跨平台统一性，因此它在浮点数方面肯定比Java更好，这意味着JIT将尽可能地达到80位。另一方面，除了观察变量的数量以确保有足够的FP寄存器之外，您无法控制其他事情。
从矢量角度讲，如果您大声尖叫，则可能是在2-3年内发生某些事情，因为Direct3D仍将以通用API的身份进入.NET，并且XNA上运行的C＃代码在Xbox whihc上运行，与CLR所能获得的裸机非常接近。这仍然意味着您需要自己执行一些中间代码。
因此，不要指望CUDA甚至没有能力链接NVIDIA库并继续前进。如果由于某种原因您真的需要“功能性”语言，因为Haskell出于纯粹的必要性而被设计为友好链接，那么您将有更多的运气尝试使用Haskell。
已经提到了Mono.Simd，虽然应该将其反向移植到CLR，但实际上可能需要做很多工作。
在social.msdn中有相当多的代码发布了在.NET中使用SSE3，C ++ / CLI和C＃，数组blitting，为perf注入SSE3代码等。
有人谈论在已编译的C＃上运行CECIL以将零件提取到HLSL中，编译到着色器中并链接粘合代码以对其进行调度（无论如何，CUDA都在进行等效操作），但是我认为这不会产生任何可运行的结果。
如果您想尽快尝试某些东西，可能会更有价值，这是Codeplex上的PhysX.Net。不要指望它会解压缩并完成魔术。但是，ih目前是活跃的作者，并且代码都是普通的C ++和C ++ / CLI，如果您想详细介绍也许对CUDA使用类似的方法，那么yopu可能会从作者那里得到一些帮助。对于全速CUDA，您仍然需要编译自己的内核，然后仅与.NET进行接口连接，因此该部分越容易变得越快乐。
有一个CUDA.NET库，该库应该是免费的，但是该页面仅提供了电子邮件地址，因此请附加一些字符串，并且在作者撰写博客时，他对库中的内容并没有特别的谈论。
哦，如果您有预算，您可能会喜欢Psi Lambda（KappaCUDAnet是.NET的一部分）。显然，他们将抬高11月份的价格（如果这不是销售技巧：-）
首先，C比C ++快得多。因此，如果您需要如此之高的速度，则应在c中创建lib等。
关于F＃，大多数基准标记使用的Mono比MS CLR慢2倍，部分原因是使用boehm GC（它们具有新的GC和LVVM，但它们仍不成熟，不支持泛型等）。
.NEt语言本身可以编译为IR（CIL），后者可以像C ++一样高效地编译为本机代码。大多数GC语言都会遇到一个问题，那就是大量的可变写入（如上所述，这包括C ++ .NET）。并且有一个特定的科学问题集对此要求，这些问题可能需要使用本机库或使用Flyweight模式重用池中的对象（从而减少写入）。原因是.NET CLR中存在写障碍，当更新参考字段（包括框）时，它将在表中设置一个位，表明该表已修改。如果您的代码包含大量此类写操作，则会受到影响。
就是说，像C＃这样的.NET应用程序使用大量的静态代码，结构和结构上的ref / out可以产生类似于C的性能，但是很难像这样编写或维护代码（如C）。
但是，F＃的亮点是对不可变数据的并行处理，这种处理与更多基于读取的问题并存。值得注意的是，大多数基准测试在可变写入中都比实际应用程序高得多。
关于浮点，由于它比较慢，因此应该使用oCaml的替代库（即.Net一个）。C / C ++允许更快地降低精度，而oCaml默认情况下不会。
最后，我将争辩说像C＃，F＃这样的高级语言和适当的配置文件，在相同的开发时间下，您会比c和C ++具有更好的性能。如果您更改瓶颈以进行ac lib pinvoke通话，则对于关键区域，您还将获得类似C的性能。就是说，如果您有无限的预算并且更在乎速度，那么与C相比，维护是行之有效的方法（不是C ++）。
最后我知道，大多数科学计算仍在FORTRAN中完成。对于线性代数问题，它仍然比其他任何东西都快-不是Java，不是C，不是C ++，不是C＃，不是F＃。LINPACK进行了很好的优化。
但是有关“您的里程可能会有所不同”的说法在所有基准测试中都是正确的。一揽子声明（我的除外）很少是真的。