最近，我一直在用C和VB.NET运行一些测试来比较执行速度。在last thread I posted中，我谈到了我如何遇到C执行速度与VB一样快的事实，但解决了这个问题。现在我的头撞到了另一堵墙：
我为VB.NET做了一个DLL来测试这个理论，并在一个程序中比较相同的VB.NET和C代码的并行执行时间。但有趣的是？VB.NET的执行时间得到了改善，现在它的执行时间与C的执行时间完全相同。花了一些时间解决这个问题，我发现Visual Studio 2008中高级编译选项中的“目标CPU”选项是罪魁祸首！
由于我运行的是64位Windows 7，我认为将目标CPU设置为x64将产生最佳的执行时间。错误。下面是一个VB.NET的Windows窗体应用程序的执行时间结果，计算10，000，000以内的所有素数并得到它们的和。
任何CPU：15.231秒
x86：10.858秒
x64：15.236秒
下面是我正在使用的代码，请随意测试它：
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Dim watch As New Stopwatch
watch.Start()
Dim maxVal As Long = 10000000
Dim sumOfPrimes As Long = 0
For i As Integer = 2 To maxVal
If (isPrime(i) = True) Then
sumOfPrimes += i
End If
Next
watch.Stop()
Console.WriteLine(watch.ElapsedMilliseconds)
Console.WriteLine("The sum of all the prime numbers below " & maxVal & " is " & sumOfPrimes)
End Sub
Function isPrime(ByVal NumToCheck As Integer) As Boolean
For i As Integer = 2 To (Math.Sqrt(CDbl(NumToCheck)))
If (NumToCheck Mod i = 0) Then
Return False
End If
Next
Return True
End Function
End Class当我运行64位时，为什么选择目标CPU为32位会导致性能提高？任何帮助这个问题将不胜感激。
3条答案
按热度按时间zbdgwd5y1#
32位和64位模式之间存在许多差异，每种差异都可能以某种方式扭曲性能差异。
在64位模式下，CPU有更多的寄存器，并且每个寄存器都更大，这使得某些操作能够更快地执行（例如，更高的寄存器计数可以避免内存访问）。
但32位至少有一个优势：
指针的宽度为32位，在64位模式下为64位。对于严重依赖指针的程序，这可能会导致64位模式下的内存使用率显着提高，这意味着CPU缓存中的程序数据比例较小，因此64位模式下的性能可能会下降，因为缓存未命中的数量更高。
另一个因素是.NET框架在这两方面并不同样出色。它们还没有在32位和64位版本的JavaScript之间实现功能对等，并且JIT可能不会像针对32位代码那样针对64位代码进行调优。
lf5gs5x22#
我在Release模式下运行了以下代码。我使用Ctrl + F5来运行代码。
AnyCPU每次都比x86快。我使用.NET 4.0。
a2mppw5e3#
.NET 3.5 SP1（即Visual Studio 2008 SP1）附带了许多性能增强，使JIT：er更有效地内联。不幸的是，这些增强功能仅针对x86：
How are value types implemented in the 32-bit CLR? What has been done to improve their performance?
然而，在.NET 4.0中，我发现x64和x86现在可以提供与x64相同或稍好的性能。