Home/ Questions/Q 1006063
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T08:23:56+00:00

Recently, I’ve been running some tests with C++ and VB.NET to compare execution speeds.

  • 0

Recently, I’ve been running some tests with C++ and VB.NET to compare execution speeds. In the last thread I posted, I talked about how I had encountered the fact that C++ was executing just as fast as VB, but got that issue resolved. Now I’m hitting my head against another wall:

I had made a DLL for VB.NET to test out this theory and compare in just one program side by side execution time of identical VB.NET and C++ code. But the interesting thing? VB.NET’s execution time improved such that it was now exactly identical to the execution time of C++. Spending some time with the problem, I discovered that the “Target CPU” option in advanced compile options in Visual Studio 2008 was the culprit!

Since I’m running 64-bit Windows 7, I figured making the target CPU x64 would yield the best execution time. Wrong. Here are the results in execution time of a Windows Forms application for VB.NET, calculating all the prime numbers up to 10,000,000 and getting their sum.

Any CPU: 15.231 seconds

x86: 10.858 seconds

x64: 15.236 seconds

Below is the code I’m using, feel free to test it yourself:

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

Why would selecting the target CPU as 32-bit when I’m running 64-bit cause a performance increase? Any help with this problem would be much appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are a number of differences between 32 and 64 bit mode, which might each skew the performance difference one way or the other.

    In 64-bit mode, the CPU has more registers, and each register is larger, which enables some operations to be performed faster (the higher register count may avoid memory accesses, for example)

    But 32-bit has at least one advantage as well:

    Pointers are 32 bits wide, where they are 64 in 64-bit mode. For programs that rely heavily on pointers, this can lead to significantly higher memory usage in 64-bit mode, which means a smaller fraction of the program data will fit in the CPU cache, and so performance may decrease in 64-bit mode, due to the higher number of cache misses.

    Another factor is that the .NET framework isn’t equally good at both. They don’t yet have feature parity between the 32- and 64-bit versions of the CLR, and the JIT might be not be tuned as well for 64-bit code as it is for the 32-bit case.

    • 0