与C＃相比，有没有人知道F＃在性能方面的衡量标准。我有一个带有大量矢量操作，光线碰撞算法等的C＃光线跟踪器，并认为它们可能更容易用F＃表示。我不是要问F＃在表达数学问题上的表现有多好，这已被回答here，而是我应该期待更好或更差的表现？由于光线跟踪是非常高性能的，即使是性能不佳的小案例也可能是错误的地方。
修改
似乎已经有很多关于这个问题的问题我找不到了（如果你实际搜索的是“F＃”这个词，那就没有结果）。一个好点here是以下答案：
F＃提供了一些与性能相关的功能 可以有所作为的功能。
首先，执行 .NET上的代表目前非常 效率低下，因而F＃使用 它自己的FastFunc类型 高性能一流 功能其次，F＃使用.NET元数据 传达内联函数以便它们 可以通过API导出 当然，这可以大大改善 在某些情况下表现。
最后，模式匹配可以 在C＃中表达非常费力 因为语言缺乏模式 匹配但几乎不可能 维护优化的C＃代码 相当于许多非平凡的模式 火柴。相比之下，F＃编译器 积极优化模式匹配 在编译期间。
相反，C＃编译器更好 使用IEnumerables优化循环 并且更善于优化 对值类型的计算（例如 复杂的算术）。
干杯，Jon Harrop。
答案 0 :(得分：7)
是的，F＃表现更好。
以下是使用不同语言实现的单线程算法的一些性能结果（基准测试神经网络的激活函数方法）：
<强> C＃：
10^7 iterations using Sigmoid1() took 3899,1979 ms
10^7 iterations using Sigmoid2() took 411,4441 ms
纯C：
10^7 iterations using sigmoid1: 628 ms
10^7 iterations using sigmoid2: 157 ms
<强> F＃：
10^7 iterations using sigmoid1: 588.843700 ms
10^7 iterations using sigmoid2: 156.626700 ms
答案 1 :(得分：2)
F＃的行为与C＃相同（因为它只是IL）。确保将矢量表示为结构 - 因为您将构建许多短暂的对象。
度量单位对性能的影响为零，实际上在编译时，度量单位信息将被完全删除。所以你实际上无法判断你的F＃代码是否具有计量单位。
答案 2 :(得分：1)
F＃的性能与C＃大致相同，它们都被编译为IL，这是重要的因素（不像IronPython和IronRuby，它们被解释，因此慢得多）。算法的性能更多地取决于它的实现而不是F＃或C＃的选择，因为F＃有助于在几行代码中实现它，你有更好的机会在F＃中发现优化而不是在C＃中。
此外文章对perf问题也有类似看法： http://diditwith.net/2008/04/03/ApplesAndOranges.aspx
答案 3 :(得分：1)
也许你已经知道了，但也许不是。
谷歌名为“Luke Hoban”，他用C＃3.0制作了一个光线追踪器，现在在微软F＃团队工作。
另请参阅：http://blogs.msdn.com/lukeh/和http://blogs.msdn.com/lukeh/archive/2007/04/03/a-ray-tracer-in-c-3-0.aspx。
他应该知道。
答案 4 :(得分：0)
事实上，从理论上讲，x86机器只能执行具有必要性的x86程序集，因此，从理论上讲，可以强制实现功能语言的性能。因此，您可以编写与F＃对应程序相同或更好的C＃程序。这里的关键字是可以。这并不意味着所有C＃程序都比F＃程序或类似程序更好。通常，在大多数问题中，F＃性能是非常可接受的。在某些情况下，F＃性能落后于C＃，但通常情况下，大多数应用程序都可以。但是，如果您希望对代码实际执行的操作进行细粒度控制，则函数式语言不适合您。 C＃中的优化机会比F＃中的优化机会多。顺便说一句，通过F＃，我并不是指编写命令式代码，而是正常的函数式方法（如果你想强制编写代码，我认为F＃没有多大意义）。
答案 5 :(得分：0)
我最初的反应是，由于C＃和F＃输出MSIL，性能将相同。但是你使用的结构可能会产生不同的IL。已在链接here on SO详细讨论了该主题。
答案 6 :(得分：0)
F＃更适合并行编程。因此，开箱即用它可以更快地作为C＃（在多核/ CPU上）。
但话说回来，你可以优化C＃来使用它，但这将会有更多的工作。