还是现在相反?
据我所知,在某些领域C#被证明比C ++更快,但是我从来没有胆量亲自测试它。
以为你们中的任何人都可以详细解释这些差异,或者将我指向正确的位置以获取有关此信息。
还是现在相反?
据我所知,在某些领域C#被证明比C ++更快,但是我从来没有胆量亲自测试它。
以为你们中的任何人都可以详细解释这些差异,或者将我指向正确的位置以获取有关此信息。
Answers:
没有严格的理由说明为什么具有JIT的基于字节码的语言(如C#或Java)不能与C ++代码一样快。但是,C ++代码在很长一段时间内过去一直明显更快,并且在许多情况下今天仍然如此。这主要是由于实施更高级的JIT优化非常复杂,而真正酷的优化才刚刚出现。
因此,在许多情况下,C ++速度更快。但这只是答案的一部分。C ++实际上更快的情况是高度优化的程序,专家程序员在其中彻底地从代码中优化了地狱。这不仅非常耗时(并因此很昂贵),而且通常会由于过度优化而导致错误。
另一方面,在以后的运行时版本(.NET CLR或Java VM)中,解释语言的代码变得更快,而无需执行任何操作。JIT编译器可以进行很多有用的优化,而这些优化在带有指针的语言中是根本不可能的。另外,有人认为垃圾回收通常应与手动内存管理一样快或更快,在许多情况下也是如此。通常,您可以使用C ++或C来实现并实现所有这些功能,但是它将变得更加复杂且容易出错。
正如Donald Knuth所说:“过早的优化是万恶之源”。如果您确实确定您的应用程序将主要由性能非常关键的算法组成,并且将成为瓶颈,并且在C ++中肯定会更快,并且您可以肯定C ++不会与其他程序冲突要求,请使用C ++。在任何其他情况下,请集中精力首先以最适合您的语言正确地实现应用程序,然后在运行速度太慢时发现性能瓶颈,然后考虑如何优化代码。在最坏的情况下,您可能需要通过外部函数接口调出C代码,因此您仍然可以用较低级的语言编写关键部分。
请记住,优化正确的程序相对容易,但是校正优化的程序要困难得多。
不可能给出实际的速度优势百分比,这在很大程度上取决于您的代码。在许多情况下,编程语言的实现甚至不是瓶颈。持怀疑态度的是http://benchmarksgame.alioth.debian.org/上的基准测试,因为这些测试代码很大程度上测试了算术代码,这很可能与您的代码根本不相似。
C#可能不会更快,但是它会使YOU / ME更快。这是我所做的最重要的衡量。:)
快了五个橙子。或更确切地说:不可能有(正确)一揽子答案。C ++是一种静态编译的语言(但随后,也进行了配置文件引导的优化),C#在JIT编译器的帮助下运行。差异如此之大,以至于甚至无法给出数量级的问题,都无法回答“更快”的问题。
首先,我将不同意对此问题的部分已接受(且被充分赞成)的回答,并指出:
实际上,有很多原因导致JITted代码的运行速度比经过适当优化的C ++(或其他没有运行时开销的语言)程序要慢,其中包括:
根据定义,在运行时花在JITting代码上的计算周期无法在程序执行中使用。
JITter中的任何热路径都将与您的代码竞争CPU中的指令和数据缓存。我们知道,就性能而言,缓存占主导地位,按照定义,像C ++这样的本地语言不具有这种类型的争用。
运行时优化的时间预算必然是多比的更多的限制编译时优化器(如另一个评论指出)
底线:最终,几乎可以肯定,您将能够在C ++中创建比在C#中更快的实现。
如此说来,到底有多快,实际上是无法量化的,因为变量太多了:任务,问题领域,硬件,实现质量以及许多其他因素。您将针对您的方案进行测试,以确定性能差异,然后确定是否值得付出额外的努力和复杂性。
这是一个非常漫长而复杂的主题,但是为了完整起见,我觉得值得一提的是C#的运行时优化器非常出色,并且能够在运行时执行某些动态优化,而这些动态优化是C ++编译时无法使用的(静态)优化器。即便如此,该优势通常仍在本机应用程序的深处,但是动态优化器是上面给出“ 几乎肯定”限定符的原因。
--
在相对性能方面,我也对在其他答案中看到的图表和讨论感到不安,因此我认为自己会很高兴,同时也为我在上面的陈述提供了支持。
这些基准测试问题的很大一部分是,您无法像编写C#一样编写C ++代码并期望获得代表性的结果(例如,在C ++中执行数千个内存分配会给您带来可怕的数字)。
相反,我写了一些更惯用的C ++代码,并与提供的C#代码@Wiory进行了比较。我对C ++代码进行的两个主要更改是:
1)使用的向量:: reserve()
2)将2d数组展平为1d,以实现更好的缓存位置(连续块)
C#(.NET 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#实现更改为相同的1d数组实现会产生Init:40ms,Fill:171ms,Total:211ms(C ++的速度仍快40%)。
用C ++设计和编写“快速”代码比用两种语言编写“常规”代码要困难得多。
在C ++中很容易获得糟糕的性能(也许)。我们看到了无保留向量的性能。这样有很多陷阱。
当您考虑运行时发生的所有事情时,C#的性能非常出色。而且该性能相对容易获得。
比较C ++和C#性能的更多轶事数据:https : //benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore
最重要的是,C ++使您可以更好地控制性能。您要使用指针吗?参考?堆栈内存?堆?动态多态还是通过静态多态(通过模板/ CRTP)消除了vtable的运行时开销?在C ++中,你必须......呃,去使所有这些选择(及以上)自己,最好让你的解决方案最好地处理问题,你的抢断。
问问自己自己是否真正想要或需要该控件,因为即使对于上述琐碎的示例,您也可以看到,尽管性能有了显着提高,但仍需要更深层次的访问投入。
int[,]
...下面是示例。
根据我的经验(并且我在两种语言上都有很多工作),与C ++相比,C#的主要问题是高内存消耗,而且我还没有找到控制它的好方法。最终将使.NET软件变慢的是内存消耗。
另一个因素是,JIT编译器不能花太多时间进行高级优化,因为它在运行时运行,如果花费太多时间,最终用户会注意到它。另一方面,C ++编译器始终需要在编译时进行优化。这个因素远不及内存消耗恕我直言。
当可以在编译时预先确定多态决策时,就会发生C ++仍占上风(并且将持续数年)的一种特殊情况。
通常,封装和延迟决策是一件好事,因为它使代码更具动态性,更易于适应不断变化的需求并且更易于用作框架。这就是为什么用C#进行面向对象编程的生产率很高,并且可以用术语“泛化”将其概括的原因。不幸的是,这种特殊的归纳是在运行时付出代价的。
通常,此成本不算什么,但是在某些应用程序中,虚拟方法调用和对象创建的开销可能有所不同(尤其是因为虚拟方法阻止了其他优化,例如方法调用内联)。这是C ++的巨大优势,因为您可以使用模板来实现另一种类型的泛化,这对运行时没有影响,但不一定比OOP的多态性小。实际上,仅使用模板技术和编译时分辨率就可以对构成OOP的所有机制进行建模。
在这种情况下(当然,它们通常仅限于特殊问题领域),C ++胜过C#和类似语言。
sort(arr, generic_comparer)
将与C ++中的手写循环一样高效。它永远不会在C#中出现。
C ++(或C)可以使您对数据结构进行细粒度的控制。如果您想旋转一下,可以选择该选项。使用Java / .NET库的内部数据结构的大型托管Java或.NET应用程序(OWB,Visual Studio 2005)随身携带了行李。我见过OWB设计者会议使用了超过400 MB的RAM和BIDS进行多维数据集或ETL设计,也使用了100 MB的内存。
在可预测的工作负载(例如大多数基准多次重复一个过程)上,JIT可以为您提供经过充分优化的代码,以至于没有实际差异。
IMO在大型应用程序上的区别不在于JIT,而是代码本身使用的数据结构。如果应用程序占用大量内存,则缓存使用率将降低。现代CPU上的高速缓存未命中代价非常高。C或C ++真正取得成功的地方是,您可以优化数据结构的使用,以更好地与CPU缓存配合使用。
对于图形,标准的C#图形类比通过C / C ++访问的GDI慢得多。我知道这与语言本身无关,与整个.NET平台无关,但是Graphics是作为GDI替代品提供给开发人员的,它的性能太差了,我什至都不敢做图形用它。
我们有一个简单的基准,用于查看图形库的速度,这就是在窗口中绘制随机线。C ++ / GDI仍然可以轻松处理10000行,而C#/ Graphics难以实时执行1000行。
垃圾回收是Java#不能用于实时系统的主要原因。
GC何时会发生?
这需要多长时间?
这是不确定的。
我们必须确定C#在性能上是否可与C ++相提并论,为此我编写了一些测试程序(两种语言均使用Visual Studio 2005)。事实证明,没有垃圾回收并且仅考虑语言(而不是框架),C#的性能基本上与C ++相同。C#中的内存分配比C ++中的内存分配要快得多,并且当数据大小增加到超出缓存行边界时,C#在确定性方面略有优势。但是,所有这些最终都需要付费,并且由于垃圾回收,C#的性能不确定,从而带来巨大的成本。
C / C ++在大型数组或数组(任意大小)上存在大量循环/迭代的程序中,其性能要好得多。这就是为什么图形在C / C ++中通常要快得多的原因,因为繁重的数组操作几乎是所有图形操作的基础。众所周知,由于所有安全检查,.NET的数组索引操作速度都很慢,对于多维数组尤其如此(而且,是的,矩形C#数组甚至比锯齿状的C#数组还要慢)。
如果您直接使用指针并避免使用Boost std::vector
和其他高级容器以及inline
所有可能的小函数,则C / C ++的优势最为明显。尽可能使用老式数组。是的,您将需要更多的代码行来完成与Java或C#相同的操作,因为避免了高级容器。如果您需要一个动态大小的数组,则只需要记住将其new T[]
与相应的delete[]
语句配对即可(或使用std::unique_ptr
)—额外速度的代价是您必须更仔细地编码。但是作为交换,您可以摆脱托管内存/垃圾收集器的开销,这很容易占Java和.NET中大量面向对象程序以及大量托管对象的执行时间的20%或更多。内存阵列索引成本。在某些特定情况下,C ++应用程序还可以从一些漂亮的编译器开关中受益。
我是C,C ++,Java和C#的专业程序员。最近,我极少有机会用后三种语言实现完全相同的算法程序。该程序有很多数学运算和多维数组运算。我在所有3种语言中都对此进行了优化。结果是我通常在较不严格的比较中所看到的典型结果:Java比C#快1.3倍(大多数JVM比CLR更优化),而C ++原始指针版本比C#快2.1倍。请注意,C#程序仅使用安全代码-我认为您最好在使用unsafe
关键字之前用C ++对其进行编码。
以免有人认为我反对C#,我最后会说C#可能是我最喜欢的语言。到目前为止,这是我遇到的最合乎逻辑,最直观,最快速的开发语言。我使用C#进行所有原型设计。C#语言比Java具有许多小的,微妙的优势(是的,我知道Microsoft可以通过较晚进入游戏并可以复制Java来解决Java的许多缺点)。敬酒Java Calendar
类的人吗?如果Microsoft花费大量精力优化CLR和.NET JITter,则C#可能会认真接管。令我感到惊讶的是,他们还没有这样做-他们在C#语言中做了很多事情,为什么不跟进大量的编译器优化呢?也许我们都乞求。
new T[]
与相应的手机配对delete[]
” –不,您不需要。还有std::unique_ptr
要为你做的。
>从我所听到的...
您的困难似乎在于确定您所听到的内容是否可信,并且当您尝试评估此站点上的答复时,只会再次遇到该困难。
您将如何确定人们在这里所说的话是否比您最初听到的话可信或更可信?
一种方法是索取证据。
当有人声称“在某些领域C#证明比C ++更快”时,问他们为什么说,请他们向您展示测量结果,请他们向您展示程序。有时他们只会犯错。有时您会发现他们只是表达一种观点,而不是分享他们可以证明是真实的东西。
人们通常会在信息和意见中混淆人们所声称的内容,而您必须尝试找出哪一个。例如,从此论坛中的答复:
“访问http://shootout.alioth.debian.org/进行基准测试 极大的怀疑,使用,因为这些测试代码很大程度上是在测试算术代码,而这些算术代码很可能与您的代码根本不相似。”
问问自己是否真的了解“这些经过大量测试的算术代码”的含义,然后问问自己作者是否真的向您表明他的主张是正确的。
“这是一个相当无用的测试,因为它实际上取决于各个程序的优化程度;我设法将其中一些程序的速度提高了4-6倍甚至更多,这清楚地表明,未优化程序之间的比较相当愚蠢。”
问问自己,作者是否真的向您表明他已经设法“将其中一些速度提高了4-6倍或更多”-这很容易做到!
对于“令人尴尬的并行”问题,当在C ++上使用Intel TBB和OpenMP时,与使用C#和TPL进行的类似(纯数学)问题相比,我发现性能提高了大约10倍。SIMD是C#不能竞争的领域,但我也觉得TPL有相当大的开销。
就是说,我只将C ++用于对性能至关重要的任务,因为我知道我将能够使用多线程并快速获得结果。对于其他所有内容,C#(偶尔还有F#)都很好。
没有真正确定的答案,这是一个非常模糊的问题。
例如; 我宁愿玩用C ++创建的3D游戏,也不愿玩C#,因为它的性能肯定要好得多。(而且我知道XNA等,但是它与真实事物几乎没有关系)。
另一方面,如前所述;您应该以一种可以快速完成所需工作的语言进行开发,然后在必要时进行优化。
.NET语言可以与C ++代码一样快,甚至更快,但是C ++代码将具有更恒定的吞吐量,因为.NET运行时必须暂停GC,即使暂停非常巧妙。
因此,即使您对运行时GC非常小心,如果您有一些必须始终快速运行且没有任何暂停的代码,.NET 有时会引入延迟。
从理论上讲,对于长时间运行的服务器类型应用程序,JIT编译的语言比本地编译的语言要快得多。由于通常将JIT编译语言首先编译为相当低级的中间语言,因此无论如何,您都可以在编译时立即进行许多高级优化。最大的优势在于,随着JIT可以获取越来越多的有关应用程序使用方式的数据,JIT可以继续动态地重新编译部分代码。它可以安排最常见的代码路径,以使分支预测尽可能频繁地成功。它可以重新排列通常一起调用的单独代码块,以将它们都保留在缓存中。它可以花费更多的精力来优化内部循环。
我怀疑这是通过.NET或任何JRE完成的,但是在我上大学时就已经对其进行了研究,因此可以认为这些事情很快就会进入现实世界并不无道理。 。
我已经vector
在C ++和C#等效语言List
以及简单的2d数组中进行了测试。
我正在使用Visual C#/ C ++ 2010 Express版本。这两个项目都是简单的控制台应用程序,我已经在标准(无自定义设置)发布和调试模式下对其进行了测试。C#列表在我的PC上运行更快,在C#中数组初始化也更快,数学运算也更慢。
我正在使用Intel Core2Duo P8600@2.4GHz,C#-.NET 4.0。
我知道矢量实现与C#列表不同,但是我只想测试用于存储对象(并能够使用索引访问器)的集合。
当然,您需要清除内存(对于的每次使用都可以说new
),但是我想保持代码简单。
C ++矢量测试:
static void TestVector()
{
clock_t start,finish;
start=clock();
vector<vector<double>> myList=vector<vector<double>>();
int i=0;
for( i=0; i<500; i++)
{
myList.push_back(vector<double>());
for(int j=0;j<50000;j++)
myList[i].push_back(j+i);
}
finish=clock();
cout<<(finish-start)<<endl;
cout<<(double(finish - start)/CLOCKS_PER_SEC);
}
C#清单测试:
private static void TestVector()
{
DateTime t1 = System.DateTime.Now;
List<List<double>> myList = new List<List<double>>();
int i = 0;
for (i = 0; i < 500; i++)
{
myList.Add(new List<double>());
for (int j = 0; j < 50000; j++)
myList[i].Add(j *i);
}
DateTime t2 = System.DateTime.Now;
Console.WriteLine(t2 - t1);
}
C ++-数组:
static void TestArray()
{
cout << "Normal array test:" << endl;
const int rows = 5000;
const int columns = 9000;
clock_t start, finish;
start = clock();
double** arr = new double*[rows];
for (int i = 0; i < rows; i++)
arr[i] = new double[columns];
finish = clock();
cout << (finish - start) << endl;
start = clock();
for (int i = 0; i < rows; i++)
for (int j = 0; j < columns; j++)
arr[i][j] = i * j;
finish = clock();
cout << (finish - start) << endl;
}
C#-数组:
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 * j;
t2 = System.DateTime.Now;
Console.WriteLine(t2 - t1);
}
时间:(发布/调试)
C ++
(是的,这是13秒,在调试模式下,列表/向量总是有问题。)
C#:
这要看情况。如果将字节码转换为机器码(而不仅仅是JIT)(我是说如果您执行该程序),并且如果您的程序使用了很多分配/取消分配,则它可能会更快,因为GC算法仅需要一次通过(理论上)通过整个内存一次,但是正常的malloc / realloc / free C / C ++调用会导致每个调用产生开销(调用开销,数据结构开销,缓存未命中;))。
因此,从理论上讲是可能的(对于其他GC语言也是如此)。
我真的没有看到无法针对大多数应用程序使用C#元编程的极端缺点,因为大多数程序员无论如何都不会使用它。
另一个很大的优势是,像LINQ “扩展” 一样,SQL为编译器提供了优化对数据库的调用的机会(换句话说,编译器可以将整个LINQ编译为一个“ blob”二进制文件,其中被调用函数可以内联或插入)。供您优化使用,但我在这里推测)。
我猜想有一些用C#编写的应用程序运行得很快,还有更多用C ++编写的应用程序运行得很快(好一点的C ++……也要使用UNIX ...)
-问题的确实是-那是什么东西,用户开发人员抱怨...
恕我直言,在C#的情况下,我们拥有非常舒适的UI,非常好的库层次结构以及CLI的整个接口系统。对于C ++,我们有模板,ATL,COM,MFC以及已经编写并正在运行的代码(如OpenGL,DirectX等)的全部代码。开发人员抱怨在C#情况下,GC调用的次数增加了(意味着程序运行很快,并且一秒钟-砰!它卡住了。
用C#编写代码非常简单快捷(不要忘记这也会增加出错的机会。对于C ++,开发人员抱怨内存泄漏,-表示崩溃,DLL之间的调用以及“ DLL地狱”-问题)支持和替换库的更新……
我认为您在编程语言中拥有的技能越多,软件的质量(和速度)就越高。
我要这样说:编写更快代码的程序员,是那些更了解当前计算机运行速度的原因的程序员,顺便说一句,他们也是使用允许精确的低级和确定性工具的适当工具的程序员。优化技术。由于这些原因,这些人就是使用C / C ++而不是C#的人。我会尽可能地陈述这一事实。
如果我没记错的话,C#模板将在运行时确定。这必须比C ++的编译时模板慢。
当您接受其他许多人提到的所有其他编译时优化时,以及缺乏安全性的确意味着更快的速度...
就原始速度和最小内存消耗而言,我想说C ++是显而易见的选择。但是,这也可以转化为更多的时间来开发代码,并确保您不会泄漏内存或引起任何空指针异常。
判决:
C#:更快的开发,更慢的运行
C ++:缓慢的开发,更快的运行。
这实际上取决于您要在代码中尝试完成的工作。我听说VB.NET,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;
}
>毕竟答案必须在某个地方,不是吗?:)
嗯不
正如一些答复所指出的那样,问题的指定方式不够明确,无法以答案的方式邀请问题。仅采取一种方式:
然后哪个程序?哪台机器?哪个操作系统?哪个数据集?
受此启发,我对大多数程序中所需的60%的普通指令进行了快速测试。
这是C#代码:
for (int i=0; i<1000; i++)
{
StreamReader str = new StreamReader("file.csv");
StreamWriter stw = new StreamWriter("examp.csv");
string strL = "";
while((strL = str.ReadLine()) != null)
{
ArrayList al = new ArrayList();
string[] strline = strL.Split(',');
al.AddRange(strline);
foreach(string str1 in strline)
{
stw.Write(str1 + ",");
}
stw.Write("\n");
}
str.Close();
stw.Close();
}
字符串数组和arraylist专门用于包含这些指令。
这是c ++代码:
for (int i = 0; i<1000; i++)
{
std::fstream file("file.csv", ios::in);
if (!file.is_open())
{
std::cout << "File not found!\n";
return 1;
}
ofstream myfile;
myfile.open ("example.txt");
std::string csvLine;
while (std::getline(file, csvLine))
{
std::istringstream csvStream(csvLine);
std::vector csvColumn;
std::string csvElement;
while( std::getline(csvStream, csvElement, ‘,’) )
{
csvColumn.push_back(csvElement);
}
for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
{
myfile << *j << ", ";
}
csvColumn.clear();
csvElement.clear();
csvLine.clear();
myfile << "\n";
}
myfile.close();
file.close();
}
我使用的输入文件大小为40 KB。
结果是-
哦,但这是在Linux上...在Mono上运行C# ...在g ++ C ++。
好的,这就是我在Windows上获得的– Visual Studio 2003: