提出结论，给出论据（一）

相关链接：
提出结论，给出论据（二）

rainbow686同学在论坛发表了这么一帖，java比.net(C#)慢这么多么？，引来讨论。回帖中不乏抛出结论但未提供任何论据的。很多myth就是在这种一传十，十传百的无论据结论中产生的；这种现象还是尽量避免的好。

rainbow686同学实施了一组对比测试，产生了一组运行结果，并得出了“确实是.net（3.5）的效率比 java（5.0）要高出很多”的结论。运行结果是实际运行所观察到的，真实可信。但得出的结论却缺乏限定条件，带有误导性。原帖里提供的代码和运行结果数据，所能支持的唯一结论是：在所测试的机器上，所使用的程序的计时方法反映了被测试程序在.NET 3.5上运行录得的时间间隔比在Java 5运行的短。其它任何衍生结论都需要更多论据予以支持，否则难以让人信服。

许多人可能都知道这种micro-benchmark往往会引出有误导性的结论，但很少人准确去解释原因。原理上：大多micro-benchmark与实际有意义的程序的结构和运行特征相去甚远，无法反映实际有意义的程序的运行状况。
但这些micro-benchmark到底是如何失衡的呢？这里我想就事论事，分析原帖中代码的一些运行细节，来提供更多材料供大家讨论。为此，本系列帖子将稍微涉及微软的CLR与Sun的HotSpot VM的工作方式。

============================================================================

CLR执行托管代码的流程

微软的用于PC上运行的.NET Framework底下的运行时叫做“公共语言运行时”（Common Language Runtime，简称CLR）。CLR实现了ECMA-335公共语言基础结构（Common Language Infrastructure，CLI）标准，并额外实现了许多方面的库。
.NET Framework 1.0、1.1、2.0、4.0都分别都自己对应的CLR版本，而.NET Framework 3.0和3.5则仍是使用CLR 2.0，.NET Framework 3.5 SP1包含了.NET Framework 2.0 SP2，其中对CLR 2.0做了更新。

CLR在执行一个托管方法时，会先看该方法是否已经被编译为本地代码；是则直接执行，否则通过即时编译（Just-In-Time compilation，简称JIT compilation，或者直接简称JIT）将MSIL字节码编译为本地代码，然后再执行该方法。一般情况下，这意味着某托管方法第一次被调用时会先被JIT然后才执行，而后续调用则可以直接执行本地代码。（例外情况：可以通过NGEN在程序执行前就预先将托管代码都编译为本地代码，或者通过RuntimeHelpers.PrepareMethod()使某方法提前被JIT）

懒得自己画图，从《CLR via C#, 2nd Edition》引用两张示意图。注意这只是示意图，不准确反映实际工作流程的细节。例如CLR 2.0的JIT其实由mscorwks.dll和mscorjit.dll配合完成，而不是通过mscoree.dll。CLR 4.0中则是clr.dll和jit.dll。
托管方法被初次调用的工作流程：


托管方法被后续调用的工作流程：

注意这里不再涉及JIT了。

============================================================================

测试的源码的总体分析

原帖中，C#部分的测试代码如下（稍做整理）：

using System;

namespace ConsoleApplication1 {
    class Program {
        static void Main( string[ ] args ) {
            long j = 1;
            Console.WriteLine( DateTime.Now.ToString( ) );
            for ( long i = 1; i < 10000000000; i++ ) {
                j = j + 1;
            }
            Console.WriteLine( DateTime.Now.ToString( ) );
        }
    }
}

这段代码有下列特征：
1、没有构造大量对象。因而不会因为分配空间与垃圾回收而影响结果。也就是说不考察GC相关；
2、没有复杂的控制流。整个Main()方法只有6个显式调用的方法（包括属性的访问器的调用），只有一个单层循环。也就是说不考察运行时对复杂控制流的优化能力。
3、用户代码中没有涉及对引用的赋值。显式使用的变量都是值类型的（包括两个long型和两个DateTime型）。这样在生成的代码里就不会出现write barrier。
4、没有复杂的数据依赖关系。注意观察，

  1) 变量j的相关计算是冗余代码，因为变量j只是重复被赋值，其已有的值没有被可见的副作用所依赖。
  在适当的优化下，j可以整个被消除而不影响程序的正确性。
  （注意这段代码里的算术运算都不是checked的，也就是说程序不关心是否发生了算术溢出；
  如果是checked的，则需要证明j的相关计算不会引发异常才可以消除掉j，因为异常是“可见的副作用”）
  2) 变量j与for循环中的循环控制变量i的值是步调一致的。在每轮for循环中，i与j的值都保持一致。
  这样j就被称为“归纳变量”（induction variable）。
  在适当的优化下，j的值不必单独计算，只要通过计算i的值即可得到，从而可以消除变量j的相关计算代码。

5、使用了超过机器字长的数据类型（对32位机器而言）。x86指令集中没有针对64位（QWORD）数据的算术运算指令，所以代码中long型的运算都得想办法映射到32位运算上。在x64、IA-64、SPARC V9之类的64位机器上则不会有这样的问题。
6、在两次计时之间有一次对标准输出流的写操作（第一个Console.WriteLine()）。显然楼主的本意只想测试循环累加的速度，这个写操作对计时带来了干扰。调用DateTime.ToString()同理，也造成了干扰。

上述测试代码的Main()方法由微软的C# 3.0编译器编译得到的MSIL如下：

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       79 (0x4f)
  .maxstack  2
  .locals init ([0] int64 j,
           [1] int64 i,
           [2] valuetype [mscorlib]System.DateTime CS$0$0000,
           [3] valuetype [mscorlib]System.DateTime CS$0$0001)
  IL_0000:  ldc.i4.1
  IL_0001:  conv.i8
  IL_0002:  stloc.0
  IL_0003:  call       valuetype [mscorlib]System.DateTime [mscorlib]System.DateTime::get_Now()
  IL_0008:  stloc.2
  IL_0009:  ldloca.s   CS$0$0000
  IL_000b:  constrained. [mscorlib]System.DateTime
  IL_0011:  callvirt   instance string [mscorlib]System.Object::ToString()
  IL_0016:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_001b:  ldc.i4.1
  IL_001c:  conv.i8
  IL_001d:  stloc.1
  IL_001e:  br.s       IL_002a

  IL_0020:  ldloc.0
  IL_0021:  ldc.i4.1
  IL_0022:  conv.i8
  IL_0023:  add
  IL_0024:  stloc.0
  IL_0025:  ldloc.1
  IL_0026:  ldc.i4.1
  IL_0027:  conv.i8
  IL_0028:  add
  IL_0029:  stloc.1
  IL_002a:  ldloc.1
  IL_002b:  ldc.i8     0x2540BE400
  IL_0034:  blt.s      IL_0020

  IL_0036:  call       valuetype [mscorlib]System.DateTime [mscorlib]System.DateTime::get_Now()
  IL_003b:  stloc.3
  IL_003c:  ldloca.s   CS$0$0001
  IL_003e:  constrained. [mscorlib]System.DateTime
  IL_0044:  callvirt   instance string [mscorlib]System.Object::ToString()
  IL_0049:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_004e:  ret
}

与实际生成的x86目标代码相比较，可以发现IL并不反映实际运行的代码的特征。
我们可以确认C#编译器没有消除变量j，所以如果实际执行时变量j消失了，那肯定是CLR的功劳。

============================================================================

生成的目标代码的总体分析

首先要声明我的测试环境，以限定我提供的论据的适用范围。我测试的机器是2004年的HP nx9040笔记本。CPU是Pentium-M 715 "Dothan"（1.5 GHz, 2MB L2 cache, 400 MHz FSB），支持指令集有MMX、SSE、SSE2，注意它不支持Intel 64指令集（或称x86-64或者x64）。内存是1280MB的DDR-266 SDRAM。操作系统是32位的Windows XP SP3。.NET Framework是3.5 SP1。

通过SOS扩展来调试，可以看到JIT为ConsoleApplication1.Program.Main()方法对应生成的x86目标代码如下：

00E70070 push        ebp
00E70071 mov         ebp,esp
00E70073 push        edi
00E70074 push        esi
00E70075 sub         esp,20h
00E70078 mov         esi,ecx
00E7007A lea         edi,[ebp-28h]
00E7007D mov         ecx,8
00E70082 xor         eax,eax
00E70084 rep stos    dword ptr es:[edi]
00E70086 mov         ecx,esi
00E70088 lea         edi,[ebp-20h]
00E7008B pxor        xmm0,xmm0
00E7008F movq        mmword ptr [edi],xmm0
00E70093 lea         ecx,[ebp-20h]
00E70096 call        792896D0
00E7009B call        792897B0
00E700A0 mov         ecx,eax
00E700A2 lea         eax,[ebp-20h]
00E700A5 sub         esp,8
00E700A8 movq        xmm0,mmword ptr [eax]
00E700AC movq        mmword ptr [esp],xmm0
00E700B1 lea         edx,[ebp-10h]
00E700B4 mov         eax,dword ptr [ecx]
00E700B6 call        dword ptr [eax+48h]
00E700B9 lea         eax,[ebp-10h]
00E700BC sub         esp,8
00E700BF movq        xmm0,mmword ptr [eax]
00E700C3 movq        mmword ptr [esp],xmm0
00E700C8 call        792DDBC0
00E700CD mov         edx,eax
00E700CF xor         ecx,ecx
00E700D1 call        792DDC30
00E700D6 mov         esi,eax
00E700D8 call        792ED2F0
00E700DD mov         ecx,eax
00E700DF mov         edx,esi
00E700E1 mov         eax,dword ptr [ecx]
00E700E3 call        dword ptr [eax+000000D8h]
00E700E9 mov         esi,1
00E700EE xor         edi,edi
00E700F0 add         esi,1
00E700F3 adc         edi,0
00E700F6 cmp         edi,2
00E700F9 jg          00E70105
00E700FB jl          00E700F0
00E700FD cmp         esi,540BE400h
00E70103 jb          00E700F0
00E70105 lea         edi,[ebp-28h]
00E70108 pxor        xmm0,xmm0
00E7010C movq        mmword ptr [edi],xmm0
00E70110 lea         ecx,[ebp-28h]
00E70113 call        792896D0
00E70118 call        792897B0
00E7011D mov         ecx,eax
00E7011F lea         eax,[ebp-28h]
00E70122 sub         esp,8
00E70125 movq        xmm0,mmword ptr [eax]
00E70129 movq        mmword ptr [esp],xmm0
00E7012E lea         edx,[ebp-18h]
00E70131 mov         eax,dword ptr [ecx]
00E70133 call        dword ptr [eax+48h]
00E70136 lea         eax,[ebp-18h]
00E70139 sub         esp,8
00E7013C movq        xmm0,mmword ptr [eax]
00E70140 movq        mmword ptr [esp],xmm0
00E70145 call        792DDBC0
00E7014A mov         edx,eax
00E7014C xor         ecx,ecx
00E7014E call        792DDC30
00E70153 mov         esi,eax
00E70155 call        792ED2F0
00E7015A mov         ecx,eax
00E7015C mov         edx,esi
00E7015E mov         eax,dword ptr [ecx]
00E70160 call        dword ptr [eax+000000D8h]
00E70166 lea         esp,[ebp-8]
00E70169 pop         esi
00E7016A pop         edi
00E7016B pop         ebp
00E7016C ret

变成了这么长一串看似混杂无章的x86代码，该如何理解呢？rainbow686同学想要测试的循环又在哪里呢？
下面我把这段代码加上注释再帖出来：

//// 代码块1：方法头
00E70070 push        ebp     // 保存帧指针
00E70071 mov         ebp,esp // 设置新的帧指针
00E70073 push        edi     // 这两句保护EDI和ESI寄存器
00E70074 push        esi
00E70075 sub         esp,20h // 分配局部变量空间
00E70078 mov         esi,ecx
00E7007A lea         edi,[ebp-28h]
00E7007D mov         ecx,8
00E70082 xor         eax,eax
00E70084 rep stos    dword ptr es:[edi]
00E70086 mov         ecx,esi
//// 代码块1结束

//// 代码块2：Program.Main()的方法体

// 内联开始，System.DateTime.get_Now()
00E70088 lea         edi,[ebp-20h]
00E7008B pxor        xmm0,xmm0
00E7008F movq        mmword ptr [edi],xmm0
00E70093 lea         ecx,[ebp-20h]
00E70096 call        792896D0 (System.DateTime.get_UtcNow(), mdToken: 060002d2)
00E7009B call        792897B0 (System.TimeZone.get_CurrentTimeZone(), mdToken: 06000942)
00E700A0 mov         ecx,eax
00E700A2 lea         eax,[ebp-20h]
00E700A5 sub         esp,8
00E700A8 movq        xmm0,mmword ptr [eax]
00E700AC movq        mmword ptr [esp],xmm0
00E700B1 lea         edx,[ebp-10h]
00E700B4 mov         eax,dword ptr [ecx]
00E700B6 call        dword ptr [eax+48h] (System.CurrentSystemTimeZone.ToLocalTime(System.DateTime), mdToken: 06000951)
// 内联结束，System.DateTime.get_Now()

// 内联开始，System.DateTime.ToString()
00E700B9 lea         eax,[ebp-10h]
00E700BC sub         esp,8
00E700BF movq        xmm0,mmword ptr [eax]
00E700C3 movq        mmword ptr [esp],xmm0
00E700C8 call        792DDBC0 (System.Globalization.DateTimeFormatInfo.get_CurrentInfo(), mdToken: 06002493)
00E700CD mov         edx,eax
00E700CF xor         ecx,ecx
00E700D1 call        792DDC30 (System.DateTimeFormat.Format(System.DateTime, System.String, System.Globalization.DateTimeFormatInfo), mdToken: 06002408)
// 内联结束，System.DateTime.ToString()

// 内联开始，System.Console.WriteLine(System.String)
00E700D6 mov         esi,eax
00E700D8 call        792ED2F0 (System.Console.get_Out(), mdToken: 06000772)
00E700DD mov         ecx,eax
00E700DF mov         edx,esi
00E700E1 mov         eax,dword ptr [ecx]
00E700E3 call        dword ptr [eax+000000D8h] (System.IO.TextWriter+SyncTextWriter.WriteLine(System.String), mdToken: 060036c5)
// 内联结束，System.Console.WriteLine(System.String)

//>> for循环初始段：对变量i赋初始值
00E700E9 mov         esi,1
00E700EE xor         edi,edi
//>> for循环体：空
//>> for循环增量段：对变量i累加
00E700F0 add         esi,1
00E700F3 adc         edi,0
//>> for循环条件ver1：
00E700F6 cmp         edi,2
00E700F9 jg          00E70105
00E700FB jl          00E700F0
//>> for循环条件ver2：
00E700FD cmp         esi,540BE400h
00E70103 jb          00E700F0
//>> for循环结束

// 内联开始，System.DateTime.get_Now()
00E70105 lea         edi,[ebp-28h]
00E70108 pxor        xmm0,xmm0
00E7010C movq        mmword ptr [edi],xmm0
00E70110 lea         ecx,[ebp-28h]
00E70113 call        792896D0 (System.DateTime.get_UtcNow(), mdToken: 060002d2)
00E70118 call        792897B0 (System.TimeZone.get_CurrentTimeZone(), mdToken: 06000942)
00E7011D mov         ecx,eax
00E7011F lea         eax,[ebp-28h]
00E70122 sub         esp,8
00E70125 movq        xmm0,mmword ptr [eax]
00E70129 movq        mmword ptr [esp],xmm0
00E7012E lea         edx,[ebp-18h]
00E70131 mov         eax,dword ptr [ecx]
00E70133 call        dword ptr [eax+48h] (System.CurrentSystemTimeZone.ToLocalTime(System.DateTime), mdToken: 06000951)
// 内联结束，System.DateTime.get_Now()

// 内联开始，System.DateTime.ToString()
00E70136 lea         eax,[ebp-18h]
00E70139 sub         esp,8
00E7013C movq        xmm0,mmword ptr [eax]
00E70140 movq        mmword ptr [esp],xmm0
00E70145 call        792DDBC0 (System.Globalization.DateTimeFormatInfo.get_CurrentInfo(), mdToken: 06002493)
00E7014A mov         edx,eax
00E7014C xor         ecx,ecx
00E7014E call        792DDC30 (System.DateTimeFormat.Format(System.DateTime, System.String, System.Globalization.DateTimeFormatInfo), mdToken: 06002408)
// 内联结束，System.DateTime.ToString()

// 内联开始，System.Console.WriteLine(System.String)
00E70153 mov         esi,eax
00E70155 call        792ED2F0 (System.Console.get_Out(), mdToken: 06000772)
00E7015A mov         ecx,eax
00E7015C mov         edx,esi
00E7015E mov         eax,dword ptr [ecx]
00E70160 call        dword ptr [eax+000000D8h] (System.IO.TextWriter+SyncTextWriter.WriteLine(System.String), mdToken: 060036c5)
// 内联结束，System.Console.WriteLine(System.String)

//// 代码块2结束

//// 代码块3：方法尾
00E70166 lea         esp,[ebp-8] // 撤销局部变量分配的空间
00E70169 pop         esi         // 恢复老的EDI和ESI
00E7016A pop         edi
00E7016B pop         ebp         // 恢复老的帧指针
00E7016C ret
//// 代码块3结束

//// Program.Main()方法结束

注意我在代码中以//>>注释的部分——那才是原帖中rainbow686同学关注的重点，for循环对应的目标代码。

============================================================================

观察方法调用的内联

方法内联（method inlining），就是用一个方法的拷贝来替代对该方法的调用。这是一种非常有效的优化：内联后程序所执行到的代码序列总是比内联前的短，因为减少了其中调用方法的相关开销；而且内联能暴露许多控制流和数据流的依赖关系，使优化器能够进行原本需要通过过程间分析才能进行的优化。其缺点是生成的目标代码体积会膨胀，会影响到指令的缓存。

注意CLR中，方法内联是如何逐层进行的。上面ConsoleApplication1.Program.Main()两次内联了System.DateTime.get_Now()。而观察后者的代码，可以发现它又内联了System.DateTime.ToLocalTime()。相关的C#源码大致如下：

public struct DateTime : IComparable, IFormattable, 
    IConvertible, ISerializable, IComparable<DateTime>, IEquatable<DateTime> {
    // ...
    public static DateTime Now {
        get {
            return DateTime.UtcNow.ToLocalTime();
        }
    }
    
    public DateTime ToLocalTime() {
        TimeZone.CurrentTimeZone().ToLocalTime(this);
    }
    // ...
}

相关的汇编代码，
System.DateTime.get_Now()：

79298CA0 push        ebp
79298CA1 mov         ebp,esp
79298CA3 push        esi
79298CA4 sub         esp,8
79298CA7 xor         eax,eax
79298CA9 mov         dword ptr [ebp-0Ch],eax
79298CAC mov         dword ptr [ebp-8],eax
79298CAF mov         esi,ecx
79298CB1 lea         ecx,[ebp-0Ch]
79298CB4 call        792896D0 (System.DateTime.get_UtcNow(), mdToken: 060002d2)
// 这里以下内联自System.DateTime.ToLocalTime()
79298CB9 call        792897B0 (System.TimeZone.get_CurrentTimeZone(), mdToken: 06000942)
79298CBE mov         ecx,eax
79298CC0 lea         eax,[ebp-0Ch]
79298CC3 push        dword ptr [eax+4]
79298CC6 push        dword ptr [eax]
79298CC8 mov         edx,esi
79298CCA mov         eax,dword ptr [ecx]
79298CCC call        dword ptr [eax+48h] (System.CurrentSystemTimeZone.ToLocalTime(System.DateTime), mdToken: 06000951)
79298CCF lea         esp,[ebp-4]
79298CD2 pop         esi
79298CD3 pop         ebp
79298CD4 ret

System.DateTime.ToLocalTime()：

79763DFC push        ebp
79763DFD mov         ebp,esp
79763DFF push        edi
79763E00 push        esi
79763E01 mov         esi,ecx
79763E03 mov         edi,edx
79763E05 call        792897B0 (System.TimeZone.get_CurrentTimeZone(), mdToken: 06000942)
79763E0A push        dword ptr [esi+4]
79763E0D push        dword ptr [esi]
79763E0F mov         ecx,eax
79763E11 mov         edx,edi
79763E13 mov         eax,dword ptr [ecx]
79763E15 call        dword ptr [eax+48h] (System.CurrentSystemTimeZone.ToLocalTime(System.DateTime), mdToken: 06000951)
79763E18 pop         esi
79763E19 pop         edi
79763E1A pop         ebp
79763E1B ret

放在一起对比看，能看出这两个方法生成的代码与前面的Main()方法中代码的关系吗？

============================================================================

观察for循环对应的目标代码

for循环对应的是这部分：

//>> for循环初始段：对变量i赋初始值
00E700E9 mov         esi,1
00E700EE xor         edi,edi
//>> for循环体：空
//>> for循环增量段：对变量i累加
00E700F0 add         esi,1
00E700F3 adc         edi,0
//>> for循环条件ver1：
00E700F6 cmp         edi,2
00E700F9 jg          00E70105
00E700FB jl          00E700F0
//>> for循环条件ver2：
00E700FD cmp         esi,540BE400h
00E70103 jb          00E700F0
//>> for循环结束

为什么简单的循环累加会看起来这么复杂呢？回忆起前面提到过的，这段代码使用了超过机器字长的数据类型，64位整型，long。既然机器没有合适的指令去执行long的算术运算，只能把它映射到32位运算上。

上面这段x86汇编，要是用C#来示意的话，类似这样：

// 把64位的i拆分为高32位的iUpper和低32位的iLower
uint iLower = 1;
int iUpper = 0;

LOOP:
iLower += 1; // 假设这个加法溢出了之后会将“carry”变量设为1，否则“carry”为0
iUpper += carry;
if (iUpper > 2) goto NEXT;
if (iUpper < 2) goto LOOP;
// 如果来到这里，则iUpper == 2
if (iLower < 0x540BE400) goto LOOP;

NEXT:

其中x86汇编里的esi对应iLower，edi对应iUpper。可以看出，esi与edi合在一起就组成了原测试代码中的i。对iLower的加法每次溢出，都意味着iUpper需要加一个进位（carry）。到这里还好理解，可是那么复杂的跳转指令是怎么回事？

想想看，10000000000 == 0x2540BE400，把它的高低32位拆开来的话，高32位就是0x2，低32位就是0x540BE400。看出这个数字与生成的汇编的关系了么？因为iUpper会记录变量i的高32位的值，无论iLower怎么变，只要iUpper还没达到2，循环就应该继续；当iUpper达到2时候，则关注点转换到iLower上，看看达到0x540BE400没有。
这段代码里，jg 00E70105（if (iUpper > 2) goto NEXT;）这句实际上是冗余的，不会影响程序的执行结果。

要是换一个数字，生成的代码还会一样吗？如果我们把原测试代码for循环部分的上限换成0x300000000，则对应生成的x86汇编是：

00E700E9 mov         esi,1
00E700EE xor         edi,edi
00E700F0 add         esi,1
00E700F3 adc         edi,0
00E700F6 cmp         edi,3    // 注意这个常量变了
00E700F9 jg          00E70101
00E700FB jl          00E700F0
00E700FD test        esi,esi  // 而这个测试条件的指令都变了
00E700FF jb          00E700F0

结构仍然是一样的，只是在与0作比较时，用TEST指令比用CMP指令更紧凑些而已。由于代码更短了，所以JG指令的跳转目标地址也与前面的版本不一样，不过这个不是我们的关注点。

好，for循环基本上分析清楚了，就是对变量i的累加和循环而已。那么变量j呢？
这里先给出结论：变量j从Main()方法中消失了。
为什么不能把j看成是与i当成同一个变量计算？如何确定它消失了？请看下回分解 ^ ^

评论

1 楼 ray_linn 2009-07-15  

说到浮点数运算：

从Java 1.4开始，Sun引进了StrictMath这么个东西，其初衷就是不管在什么样的硬件平台上，什么样的OS下，Java的数值计算结果要保持高度的一致，都要符合所谓新的IEEE的标准。结果呢，Sun选择了自由软件fdlibm库函数来作为Java的native code。

将scimark2中较少调用的函数，比如pow, exp, sqrt, log等等单独算算，还是有区别的。