I used VS2005 professional to compile 18 .Net assemblies using the AnyCPU platform setting in configuration manager. I also have a startup executable that calls into one of the GAC libraries to start/run the program.
I compiled both the program and all assemblies on at 32 bit Windows 2000 OS using the "AnyCPU" platform setting
On the 64-bit computer running XP-Professional(64)...
All assemblies were successfully loaded as 64-bit gac assemlblies using \v2.0 64 bit\bin\gacutil.exe. The startup program is shown running without the "*32 "suffix. The program is running but from "program performance" its behavior appears to provide perforrmance that would be expected on a 32-bit machine.
Is this possible Am I doing something wrong That is, could I be doing something so that I am not benefiting from 64-bit performance at all
P.S. I have run this program before in 64-bit mode but with 2 (3) major differences
a) The .Net version was VS 2005 Beta2
b) I compiled the code on the XP64 OS and specifically targeted the code to the "x64 platform" .
The reason that I suspect a performance issue is that the program is now taking twice a long as it was under Net 2.0 Beta2, after having recompiled all program libraries (assemblies). The reason that this is such an issue is that the program will take months to run to its full completion so 2 months will now take 4 months!!!!
Will AnyCPU cause binaries to run as 64-bit on x64 machine
NimmerSoft
Vitek Karas
Here is a better method. It uses reflection to see the location of the loaded assemblies.
Dim b64 As Boolean = False For Each a As Reflection.Assembly In My.Application.Info.LoadedAssemblies If a.Location.ToLower.Contains("framework64") Then b64 = True Next Me.Text = IIf(b64, "64 Bit", "32 Bit").ToStringjordanb412
James Xiao
Josh:
Thanks for your response.
This isn't an exact comparison but I just tested the exact same code running on a 32-bit processor. On the 32-bit OS I am running under Beta2. It is more or less taking the same amout of time (adjusting for slightly differing dual processor speeds on the 2 machines). I hadn't tested this but your response motivated me (embarassed me) to do so. I hate to admit it but I am running the Beta 2 version on the 32-bit server as we don't have the money for the "team suite" (i.e as you suggested I am also looking for performance bottlenecks).
Peformance bottlenecks aside , this is strange. As per Ken's suggestion I confirmed that the program appears to be running as 64-bit. The \Framework64\v2.0.50727\mscorlib.dll is being loaded on the x64 OS. Furthermore, I confirmed that it was loading all my libraries, after having recompiled them to target the x64 platform. This is a CPU intensive simulation model and I was getting about 65-70% better peformance on the x64 OS before installing V2.0 (when running under Beta 2). As you state, I can't believe that performance got worse going from Beta 2 to V 2.0. In fact, you suggest that if anything it should be slightly better.
Jim Savarino
Group Health Cooperative
Seattle WA
MrCrool
Ken:
What a great idea....I didn't include my "x64 assmbly information" but all of my libraries are loading correctly. The assembly location is shown along with the assembly fullname on the following line(s). The third line contains the host context (0) however defined, and true means that the assembly was loaded from the GAC. Certainly the x64 core library was loaded. I assume that it would have loaded corresponding 64-bit versions of System, System.Xml, and System.Configuration although from the output one can't really tell. So this is a mystery as to why my performance has all of the sudden "halved".
Jim Savarino
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
0:True
C:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll
System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
0:True
C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
0:True
C:\WINDOWS\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll
System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
0:True
fshey
You can always check IntPtr.Size, if it is 8 you are running 64-bit, if it is 4 you are running 32-bit.
However, if you see it showing up in Task Manager without the *32 then it is definitely running as a 64-bit application. It would probably be worth profiling your application to figure out where the bottleneck is, to my knowledge we didn't regress many performance scenarios from Beta2 to RTM on 64-bit, we did improve a number of them.
-josh
http://blogs.msdn.com/joshwil
Ram Kinkar Pandey
Josh:
I realized that that was pretty confusing....something like this (per model iteration)
beta2 rtm
x64 3 min 20 sec 7 min 30 sec
x86 7 min 20 sec unknown
Jim Savarino
BuffyBot
Those numbers are interesting to me. Do you have an opportunity to measure the beta2 x64 number again just to make sure it wasn't a fluke I've had a number of cases where i've made spurious measurements of things that have led me down a path of trying to find a problem that doesn't exist.
That said, what is the characterization of the problem that your application is trying to solve. It is somewhat unusual to see scenarios that are 2x improved simply by moving to 64-bit unless they almost all 64-bit math or are highly memory constrained on 32-bit.
-josh
http://blogs.msdn.com/joshwil
HLdeveloper
Ken :
This is an interesting idea. Ideally it would work the other way around. That is work only in 64-bit mode. And now that you mention it, too bad that Microsoft didn't add some sort of call so that an assembly could tell you what mode it was running under (64 bit or 32 bit). I probably don't know what I am talking about here. That is, I'll bet what is going on is much more complex than I am implying.
Thanks ...
Jim Savarino
Vadim_Luk
Josh:
Those numbers reflect repeated measures (more like the mean) from repeated observations on iterations. I can inspect the time of each simulation model iteration. This is a "very math intensive" Bayesian calibration model. This is why the "time of each iteration" is so important. We have calibrated our model by running this program for 3 months , starting and stopping every 2 weeks to "reseed" the model. The only numbers that are currently directly comparable are the x86-beta2 and x64-rtm. That is , I "know" that these 2 programs are executing identical code on the differing operating systems. Both models are currently up and running and I can inspect the logfile to see the time that it takes for each iteration.
If you are interested in what we are doing we are simulating the "probablistic evolution" of adenomas in the intestine and their likely transition to cancer in order to evaluate the efficacy of alternative screening modalities on reducing the likelihood of colorectal cancer.
Jim Savarino
Group Health Cooperative
Seattle WA
Ed_Zero
I thought that I would update these numbers after doing a more controlled test. To the best of my knowledge, the following statistics are based on running the exact same code with the exact same configuration settings and starting values.
beta2 rtm
x64 7 min 17 sec (based on mean of 21 trials)
x86 6 min 15 sec (mean of 25 trials)
x64 computer is running XP64 Professional on a Dell Precision 670 with dual 3.60 ghz processors, with hyperthreading enabled
x86 computer is running XP Professional on a Dell Precision 470 with dual 3.2 ghz processors, with hyperthreading enabled
so the difference in performance is even greater than it appears. No other jobs of any signficance is taking up a major portion of CPU time.
I don't want to discourage anyone from "jumping in" as I think that there are substantive performance improvements to be gained by running under the XP64 OS. I just wish that it were easier to move code between the 2 platforms. As previously mentioned, I strongly suspect that I am doing something wrong when either compiling or loading this code. It took me awhile about 4 months ago, but I had the beta2 version on the XP64 OS averaging close to (down to) 3 minutes per trial. That is I kept on recompiling and reloading the dll's until "thru magic" I more or less doubled my performance which was beyond my expectations.
Jim Savarino
Ernesto Dos Santos Afonso
Ken:
You, more or less answered my question. Thank you.
I can't post the code as it is a very complex simulation model. Yesterday, I recompiled and reloaded the assemblies after setting the target platform to "x64". There was no improvement in performance. The strange thing is that this model was running twice as fast before. To my knowledge I have made no subtantive changes to the code. That is, no code changes that would have caused such a deterioration in performance.
The first time that I tried this there was one assembly that appeared to cause the whole simulation model to "thunk down" (for lack of a better expression) to 32-bit mode/performance. That is, after targeting this assembly, recompiling as "x64" on the XP64 OS, system performance doubled. The one thing that I haven't tried is compiling the code on the XP64 OS which I am assuming should make no difference (but this is one difference that still remains).
I wish that there was some way of determining whether each specific binary were in fact running in 64-bit mode.
Jim Savarino
Martin Mason
By the way: What does performance look like on the 32-bit version of .Net 2.0, was there a change from Beta2 to RTM
-josh
http://blogs.msdn.com/joshwil
sqsAndres
I am not sure that I understand the exact relationship of the numbers to the versions of the framework, can you give me a breakdown in a table of the time for:
beta2 rtm
x64 x y
x86 a b
-josh
http://blogs.msdn.com/joshwil