C ++ / CLI最快的编译器？是的，至少对我而言。 :-) [英] C++/CLI the fastest compiler? Yes, at least for me. :-)
问题描述
好的，所以我之前发布了一篇关于缺乏C ++ / CLI市场营销的咆哮，
并且它分成另一个关于哪个更快的
编译器的咆哮。有人说C＃和C ++ / CLI一样快，而其他人则表示
C ++ / CLI更优化了。
无论如何，我写了一些非常简单的测试代码，至少在我的b $ b计算机上C ++ / CLI出来的速度最快。这是示例代码，只是
我在java中写了一个很好的度量，它是最慢的！ ;-)另外，
我没有优化编译器开关并使用
/ clr编译C ++ / CLI：安全只能编译为纯可验证的.net。
// C ++ / CLI代码
使用命名空间系统;
int main（）
{
long start = Environment :: TickCount;
for（int i = 0; i< 10000000; ++ i）{}
long end =环境:: TickCount;
Console :: WriteLine（结束 - 开始）;
}
// C＃代码
使用系统;
公共类ForLoopTest
{
public static void Main（string [] args）
{
long start = Environment.TickCount;
for（int i = 0; i< 10000000; ++ i） {}
long end = Environment.TickCount;
Console.WriteLine（（end-start））;
}
}
// Java代码
公共类性能
{
public static void main（String args []）
{
long s tart = System.currentTimeMillis（）;
for（int i = 0;我<千万; ++ i）{}
long end = System.currentTimeMillis（）;
System.out.println（end-start）;
}
}
结果：
C ++ / CLI - > 15-18秒
C＃ - > 31-48秒
Java - > 65-72秒
我知道，我知道，这种测试并不总是万无一失，结果
因计算机而异，但是至少在我的系统上，C ++ / CLI的结果是最快的结果。
也许C ++ / CLI是最优化的编译器？
-Don Kim
Ok, so I posted a rant earlier about the lack of marketing for C++/CLI,
and it forked over into another rant about which was the faster
compiler. Some said C# was just as fast as C++/CLI, whereas others said
C++/CLI was more optimized.
Anyway, I wrote up some very simple test code, and at least on my
computer C++/CLI came out the fastest. Here''s the sample code, and just
for good measure I wrote one in java, and it was the slowest! ;-) Also,
I did no optimizing compiler switches and compiled the C++/CLI with
/clr:safe only to compile to pure verifiable .net.
//C++/CLI code
using namespace System;
int main()
{
long start = Environment::TickCount;
for (int i = 0; i < 10000000; ++i) {}
long end = Environment::TickCount;
Console::WriteLine(end - start);
}
//C# code
using System;
public class ForLoopTest
{
public static void Main(string[] args)
{
long start = Environment.TickCount;
for (int i =0;i < 10000000; ++i) {}
long end = Environment.TickCount;
Console.WriteLine((end-start));
}
}
//Java code
public class Performance
{
public static void main(String args[])
{
long start = System.currentTimeMillis();
for (int i=0; i < 10000000; ++i) {}
long end = System.currentTimeMillis();
System.out.println(end-start);
}
}
Results:
C++/CLI -> 15-18 secs
C# -> 31-48 secs
Java -> 65-72 secs
I know, I know, these kind of test are not always foolproof, and results
can vary by computer to computer, but at least on my system, C++/CLI had
the fastest results.
Maybe C++/CLI is the most optimized compiler?
-Don Kim
推荐答案
Don Kim写道：
Don Kim wrote:
C ++ / CLI - > ; 15-18秒
C＃ - > 31-48秒
Java - > 65-72秒
我知道，我知道，这种测试并非总是万无一失，而且结果因计算机而异，但至少在我的系统上， C ++ / CLI的结果最快。
也许C ++ / CLI是最优化的编译器？
C++/CLI -> 15-18 secs
C# -> 31-48 secs
Java -> 65-72 secs
I know, I know, these kind of test are not always foolproof, and
results can vary by computer to computer, but at least on my system,
C++/CLI had the fastest results.
Maybe C++/CLI is the most optimized compiler?
增加循环的长度后通过100倍，我看到C ++ / CLI的速度优势还有2倍的速度优势。查看由
两个编译器生成的IL各自的主要功能：
C ++：
。 .method assembly static int32 main（）cil managed
{
//代码大小40（0x28）
.maxstack 2
.locals（int32 V_0，
int32 V_1，
int32 V_2）
IL_0000：call int32 [mscorlib] System.Environment :: get_TickCount（）
IL_0005：stloc.2
IL_0006：ldc.i4.0
IL_0007：stloc.0
IL_0008：br.s IL_000e
//循环开始
IL_000a：ldloc.0
IL_000b：ldc.i4。 1
IL_000c：添加
IL_000d：stloc.0
IL_000e：ldloc.0
IL_000f：ldc。 i4 0x3b9aca00
IL_0014：bge.s IL_0018
IL_0016：br.s IL_000a
//循环结束
IL_0018：调用int32 [mscorlib] System.Environment :: get_TickCount（）
IL_001d：stloc.1
IL_001e ：ldloc.1
IL_001f：ldloc.2
IL_0020：sub
IL_0021：call void [mscorlib] System.Console :: WriteLine（ int32）
IL_0026：ldc.i4.0
IL_0027：ret
} //方法结束''全局函数''::主要
C＃：
..method public hidebysig static void Main（string [] args）cil managed
{
.entrypoint
//代码大小47（0x2f）
.maxstack 2
.locals init （int64 V_0，
int32 V_1，
int64 V_2，
bool V_3）
IL_0000：nop
IL_0001：调用int32 [mscorlib] System.Environment :: get_TickCount（）
IL_0006：conv.i8
IL_0007：stloc.0
IL_0008：ldc.i4.0
IL_0009：stloc.1
IL_000a：br.s IL_0012
//开始循环
IL_000c：nop
IL_000d：nop
IL_000e：ldloc.1
IL_000f：ldc.i4 .1
IL_0010：添加
IL_0011：stloc.1
IL_0012：ldloc.1
IL_0013：ldc.i4 0x3b9aca00
IL_0018 ：clt
IL_001a：stloc.3
IL_001b：ldloc.3
IL_001c：brtrue.s IL_000c
//循环结束
IL_001e：调用int32 [mscorlib] System.Environment :: get_TickCount（）
IL_0023：conv.i8
IL_0024 ：stloc.2
IL_0025：ldloc.2
IL_0026：ldloc.0
IL_0027：sub
IL_0028 ：call void [mscorlib] System.Console :: WriteLine（int64）
IL_002d：nop
IL_002e：ret
} //结束方法ForLoopTest :: Main
C ++编译器确实生成了更优化的IL。令我感到惊讶的是，JIT并没有更好地优化C＃生成的代码。
注意C＃代码将时间转换为64位值（C＃的长度是64位/ b $ b位，而C ++的长度是32位），但是这种情况发生在循环之外所以它是
应该对代码的整体速度没有影响。
-cd
After increasing the length of the loops by a factor of 100, I see about a
2X speed advantage for C++/CLI as well. Looking at the IL produced by the
two compilers for the respective main functions:
C++:
..method assembly static int32 main() cil managed
{
// Code size 40 (0x28)
.maxstack 2
.locals (int32 V_0,
int32 V_1,
int32 V_2)
IL_0000: call int32 [mscorlib]System.Environment::get_TickCount()
IL_0005: stloc.2
IL_0006: ldc.i4.0
IL_0007: stloc.0
IL_0008: br.s IL_000e
// start of loop
IL_000a: ldloc.0
IL_000b: ldc.i4.1
IL_000c: add
IL_000d: stloc.0
IL_000e: ldloc.0
IL_000f: ldc.i4 0x3b9aca00
IL_0014: bge.s IL_0018
IL_0016: br.s IL_000a
// end of loop
IL_0018: call int32 [mscorlib]System.Environment::get_TickCount()
IL_001d: stloc.1
IL_001e: ldloc.1
IL_001f: ldloc.2
IL_0020: sub
IL_0021: call void [mscorlib]System.Console::WriteLine(int32)
IL_0026: ldc.i4.0
IL_0027: ret
} // end of method ''Global Functions''::main
C#:
..method public hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 47 (0x2f)
.maxstack 2
.locals init (int64 V_0,
int32 V_1,
int64 V_2,
bool V_3)
IL_0000: nop
IL_0001: call int32 [mscorlib]System.Environment::get_TickCount()
IL_0006: conv.i8
IL_0007: stloc.0
IL_0008: ldc.i4.0
IL_0009: stloc.1
IL_000a: br.s IL_0012
// start of loop
IL_000c: nop
IL_000d: nop
IL_000e: ldloc.1
IL_000f: ldc.i4.1
IL_0010: add
IL_0011: stloc.1
IL_0012: ldloc.1
IL_0013: ldc.i4 0x3b9aca00
IL_0018: clt
IL_001a: stloc.3
IL_001b: ldloc.3
IL_001c: brtrue.s IL_000c
// end of loop
IL_001e: call int32 [mscorlib]System.Environment::get_TickCount()
IL_0023: conv.i8
IL_0024: stloc.2
IL_0025: ldloc.2
IL_0026: ldloc.0
IL_0027: sub
IL_0028: call void [mscorlib]System.Console::WriteLine(int64)
IL_002d: nop
IL_002e: ret
} // end of method ForLoopTest::Main
The C++ compiler did generate more optimized IL. It''s surprising to me that
the JIT didn''t do a better job of optimizing the C#-produced code.
Note that the C# code converted the time to a 64 bit value (C#''s long is 64
bits, while C++''s long is 32 bits), but that occurred outside the loop so it
should have next to no impact on the overall speed of the code.
-cd
嗨卡尔！
Hi Carl!
C ++编译器确实生成了更优化的IL。令我感到惊讶的是，JIT并没有更好地优化C＃生成的代码。
The C++ compiler did generate more optimized IL. It''s surprising to me that
the JIT didn''t do a better job of optimizing the C#-produced code.
不是吗？有一个声明表明JIT for .NET 2.0没有进行优化（只有简单的优化）？
我只记得blogs.msdn上的某个博客文章。 com ...但是
再也找不到了...
-
问候
Jochen
我关于Win32和.NET的博客
http://blog.kalmbachnet.de/
>> C ++编译器确实生成了更优化的IL。令人惊讶的是
>> The C++ compiler did generate more optimized IL. It''s surprising to
我认为JIT在优化C＃生成的代码方面没有做得更好。
me that the JIT didn''t do a better job of optimizing the C#-produced
code.
没有声明JIT for .NET 2.0没有进行优化（只是简单的优化）？
我只记得来自某人的博客文章blogs.msdn.com ...但是
无法再找到它了......
Wasn?′t there a statement that the JIT for .NET 2.0 is not doing
optimizations (only simple optimizations) ?
I just remember a blog-entry from someone at blogs.msdn.com... but
couldn?′t find it anymore...
目前我只能找到缺少
优化CF.但我认为
桌面框架也是如此...
http://blogs.msdn.com/stevenpr/archi...12/502978.aspx
< quote>
因为CLR可以在内存压力下丢弃本机代码，或者当
时应用程序移到后台，当应用程序
继续运行时，很可能需要再次jit编译
相同的IL代码。这个事实导致了我们的第二个主要jit编译器
设计决策：编译IL代码所需的时间通常比生成的本机代码的质量优先于
。与所有
好的编译器一样，Compact Framework jit编译器会进行一些基本的优化，但由于需要快速重新生成代码，所以需要在
要求应用程序保持响应，更广泛
优化通常会降低剪切编译速度。
< / quote>
-
问候
Jochen
关于Win32和.NET的博客
http://blog.kalmbachnet.de/
这篇关于C ++ / CLI最快的编译器？是的，至少对我而言。 :-)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
