还是现在反过来了?
据我所知,c#在某些领域被证明比c++更快,但我从来没有勇气亲自测试它。
我想你们任何人都可以详细解释这些差异,或者告诉我有关信息的正确位置。
还是现在反过来了?
据我所知,c#在某些领域被证明比c++更快,但我从来没有勇气亲自测试它。
我想你们任何人都可以详细解释这些差异,或者告诉我有关信息的正确位置。
当前回答
我知道这不是你想问的,但是c#通常比c++写得更快,这在商业环境中是一个很大的好处。
其他回答
我发现2020年4月读过:https://www.quora.com/Why-is-C-so-slow-compared-to-Python,作者是一位拥有15年以上软件开发经验的现实世界的程序员。
它指出,c#通常较慢,因为它被编译为公共中间语言(CIL),而不是像c++那样的机器代码。然后,CIL通过公共语言运行库(CLR)输出机器代码。但是,如果您继续执行c#,它将获取机器代码的输出并缓存它,以便为下次执行保存机器代码。总而言之,如果多次执行,c#会更快,因为它是多次执行后的机器代码。
也有评论说,一个优秀的c++程序员可以做一些耗时的优化,但最终会被优化。
如果我没记错的话,c#模板是在运行时确定的。这肯定比c++的编译时模板慢。
当你考虑到很多人提到的所有其他编译时优化,以及安全性的缺失,确实意味着更高的速度……
我想说,就原始速度和最小内存消耗而言,c++是显而易见的选择。但这也转化为更多的时间来开发代码,并确保您不会泄漏内存或导致任何空指针异常。
结论:
c#:更快的开发,更慢的运行 c++:开发慢,运行快。
这实际上取决于你想在代码中实现什么。我听说这只是一个都市传说,VB和VB之间有性能上的差异。NET, c#和托管c++。然而,我发现,至少在字符串比较中,托管c++胜过c#,而c#又胜过VB.NET。
我并没有对这两种语言的算法复杂度做过详尽的比较。我也只是使用每种语言的默认设置。在VB。NET我使用设置要求声明变量,等等。下面是我用于托管c++的代码:(正如你所看到的,这段代码非常简单)。我用。net 4.6.2在Visual Studio 2013的其他语言中运行相同的程序。
#include "stdafx.h"
using namespace System;
using namespace System::Diagnostics;
bool EqualMe(String^ first, String^ second)
{
return first->Equals(second);
}
int main(array<String ^> ^args)
{
Stopwatch^ sw = gcnew Stopwatch();
sw->Start();
for (int i = 0; i < 100000; i++)
{
EqualMe(L"one", L"two");
}
sw->Stop();
Console::WriteLine(sw->ElapsedTicks);
return 0;
}
据我所知…
你的困难似乎在于决定你所听到的是否可信,当你试图评估这个网站上的回复时,这个困难将会重复。
你将如何判断人们在这里所说的比你最初听到的更可信还是更不可信?
一种方法是要求提供证据。
当有人声称“在某些领域c#被证明比c++快”时,问他们为什么这么说,让他们给你看测量结果,让他们给你看程序。有时他们只是犯了一个错误。有时你会发现他们只是在表达一种观点,而不是分享一些他们可以证明是正确的事情。
通常情况下,信息和观点会混淆在人们的说法中,你必须试着分清哪个是哪个。例如,从这个论坛的回复中:
"Take the benchmarks at http://shootout.alioth.debian.org/ with a great deal of scepticism, as these largely test arithmetic code, which is most likely not similar to your code at all." Ask yourself if you really understand what "these largely test arithmetic code" means, and then ask yourself if the author has actually shown you that his claim is true. "That's a rather useless test, since it really depends on how well the individual programs have been optimized; I've managed to speed up some of them by 4-6 times or more, making it clear that the comparison between unoptimized programs is rather silly." Ask yourself whether the author has actually shown you that he's managed to "speed up some of them by 4-6 times or more" - it's an easy claim to make!
首先,我不同意这个问题的部分公认答案(并且得到了好评),我说:
为什么jit代码比适当优化的c++(或其他没有运行时开销的语言)运行得慢,实际上有很多原因。 程序包括:
根据定义,在运行时用于jit代码的计算周期在程序执行中不可用。 JITter中的任何热路径都将与你的代码竞争指令和CPU中的数据缓存。我们知道缓存在性能方面占主导地位,而像c++这样的原生语言在设计上并没有这种类型的争用。 运行时优化器的时间预算必然比编译时优化器的时间预算更有限(正如另一个评论者指出的那样)。
底线:最终,您几乎肯定能够在c++中创建比在c#中更快的实现。
现在,说了这么多,速度到底有多快是无法量化的,因为有太多的变量:任务、问题领域、硬件、实现质量和许多其他因素。您将在您的场景上运行测试,以确定性能上的差异,然后决定是否值得额外的努力和复杂性。
这是一个很长很复杂的话题,但为了完整起见,我觉得值得一提的是,c#的运行时优化器非常出色,能够在运行时执行某些c++编译时(静态)优化器无法实现的动态优化。即便如此,优势仍然主要体现在本机应用程序方面,但动态优化器是上面给出的“几乎肯定”限定符的原因。
--
在相对性能方面,我也被我在其他一些答案中看到的数字和讨论所困扰,所以我想我应该插话,同时为我上面所做的陈述提供一些支持。
这些基准测试的很大一部分问题是,你不能像写c#一样写c++代码,并期望得到具有代表性的结果(例如。在c++中执行成千上万的内存分配将会给你可怕的数字。)
相反,我编写了稍微更习惯的c++代码,并与@Wiory提供的c#代码进行了比较。我对c++代码所做的两个主要更改是:
使用向量::储备() 将2d数组平摊到1d以获得更好的缓存位置(连续块)
c#(。净4.6.1)
private static void TestArray()
{
const int rows = 5000;
const int columns = 9000;
DateTime t1 = System.DateTime.Now;
double[][] arr = new double[rows][];
for (int i = 0; i < rows; i++)
arr[i] = new double[columns];
DateTime t2 = System.DateTime.Now;
Console.WriteLine(t2 - t1);
t1 = System.DateTime.Now;
for (int i = 0; i < rows; i++)
for (int j = 0; j < columns; j++)
arr[i][j] = i;
t2 = System.DateTime.Now;
Console.WriteLine(t2 - t1);
}
运行时间(发布):初始:124ms,填充:165ms
C++14 (Clang v3.8/C2)
#include <iostream>
#include <vector>
auto TestSuite::ColMajorArray()
{
constexpr size_t ROWS = 5000;
constexpr size_t COLS = 9000;
auto initStart = std::chrono::steady_clock::now();
auto arr = std::vector<double>();
arr.reserve(ROWS * COLS);
auto initFinish = std::chrono::steady_clock::now();
auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);
auto fillStart = std::chrono::steady_clock::now();
for(auto i = 0, r = 0; r < ROWS; ++r)
{
for (auto c = 0; c < COLS; ++c)
{
arr[i++] = static_cast<double>(r * c);
}
}
auto fillFinish = std::chrono::steady_clock::now();
auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);
return std::make_pair(initTime, fillTime);
}
运行时间(发布):初始:398µs(是的,这是微秒),填充:152ms
总运行时间:c#: 289毫秒,c++ 152毫秒(大约快90%)
观察
Changing the C# implementation to the same 1d array implementation yielded Init: 40ms, Fill: 171ms, Total: 211ms (C++ was still almost 40% faster). It is much harder to design and write "fast" code in C++ than it is to write "regular" code in either language. It's (perhaps) astonishingly easy to get poor performance in C++; we saw that with unreserved vectors performance. And there are lots of pitfalls like this. C#'s performance is rather amazing when you consider all that is going on at runtime. And that performance is comparatively easy to access. More anecdotal data comparing the performance of C++ and C#: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore
归根结底,c++为您提供了对性能的更多控制。你想用指针吗?一个参考吗?栈内存?堆吗?动态多态还是用静态多态(通过模板/CRTP)消除虚表的运行时开销?在c++中你必须…呃,自己做出所有这些选择(甚至更多),理想情况下,这样你的解决方案才能最好地解决你正在处理的问题。
问问自己是否真的想要或需要该控件,因为即使对于上面的简单示例,您也可以看到尽管性能有了显著的改进,但它需要更深入的投资才能访问。