Compartilhar via

Managed Code on 64-Bit Windows Platforms

  • Artigo

Posted November 14, 2004

Chat Date: November 9, 2004

Please note: Portions of this transcript have been edited for clarity

Introduction

Anne MSFT (Moderator):
Welcome to today’s chat about “Managed Code on 64-Bit Windows Platforms.” We are pleased to welcome our experts for today. I will have them introduce themselves now.

Larry Sullivan (Expert):
I am the Development Lead for the 64bit CLR and drive the 64bit effort in the Developer Division. I have been working on the CLR from its inception and have been at Microsoft for 10+ years working on a variety of technologies including Windows 95, Internet Explorer and the .Net Framework.

Anne MSFT (Moderator):
We are also joined by Surupa, program manager for 64-bit CLR.

Start of Chat

Larry Sullivan (Expert):
Q: Will .NET mappings of C++/CLI change in .NET 64? For example int will still be 16 bit?
A: No, the size of int's etc...remain the same. References grow to become 64bit sized and if you are passing an object ref to unmanaged code you will want to use Int.Ptr because it is a type that will change based on the platform.

Larry Sullivan (Expert):
Q: Will 32-bit managed applications run on .NET 64?
A: 32 bit applications built with v1.0 or v1.1 will always run as 32 bit applications. On 64bit these applications will run in the WOW. If you build an agnostic application in Whidbey, C# has this as AnyCPU, then it will run as a 32bit application on a 32bit platform and a 64bit application on a 64bit platform. You can make your application 32bitrequired if you are using a 32 bit COM object that doesn't have a counter part for 64bit.

Larry Sullivan (Expert):
Q: Without recompilation?
A: Yes they can. Please see my additional reply.

Larry Sullivan (Expert):
Q: Shouldn't Longhorn/WinFX be directly 64-bit since the beginning?
A: Yes, WinFx will run on all platforms when it ships.

Surupa MSFT (Expert):
Q: Besides the larger memory address and data types how will the 64 bit improve performance?
A: Computations are faster, data transfer rates are higher

Larry Sullivan (Expert):
Q: OK, I've got a question regarding .NET on IA64. A test managed program creates custom objects of 16 size up to all the virtual memory is exhausted (OutOfMemoryException thrown). Build as Anycpu - 1316 objects created, build as IA64 target - just 1315.
A: Without seeing what is happening here is why I think you are not seeing the number increase as much as expected. Even though your data is a fixed size the overhead in the CLR of objects is double. All GC references are 64bit for example. I will have my team look at the issue but what we have seen is that for lots of objects the overhead of larger pointer sizes has an effect.

Larry Sullivan (Expert):
Q: The difference is not valuable, but the question: does specification of target increases memory overhead for managed code?
A: The specification of target does not directly affect the memory overhead for managed code. For unmanaged C++ is does. For managed it will affect where the code runs and indirectly have the overhead grow. I hope that makes sense.

Larry Sullivan (Expert):
Q: Is it recommended to use Anycpu to reach better performance?
A: Not so much performance. AnyCPU is really about reach of platform and if your code can run on all platforms then this is the right choice, but if you use a COM object through Interop and that object doesn't exist for 64bit then you will need to mark your application as x86.

Larry Sullivan (Expert):
Q: why would 64 bit make computation faster. having the same speed chip but 32 vs 64 bit, shouldn't the computation speed be the same? Also why would 64 bit make data transfer faster? Everything is addressed as 64bit so it's not like it can squeeze two 32
A: Just the move to 64bit by itself does not improve performance. For large memory based applications then having more info in memory will help. For very reference/pointer intensive code then you can see a drop in performance. Also the larger code can cause more cache misses, but our experience is that the native C/C++ compiler and our JIT can produce code that results in very good performance on these machines. It does come down to the type of code you are developing.

Larry Sullivan (Expert):
Q: Is there any chance to get 32bit assemblies loaded/working for SQL Server 2005 64bit?
A: Yes, if they are built AnyCPU, which for SQL 2005 they can be then they will run on both.

Surupa MSFT (Expert):
Q: What would be the benefit to mark an application as AnyCPU/64 when it can be executed as 32-bit?
A: If you mark it as AnyCPU then it becomes an agnostic assembly that will run on both 32-bit and 64-bit - so basically the same code would run on both platforms without having to recompile it.

Surupa MSFT (Expert):
Q: Will FxCop have special rules for 64bit conformance checks?
A: Yes, we do - for Pinvoke, COM Interop and some others.

Surupa MSFT (Expert):
Q: What is "WOW"?
A: WOW is Windows 32-bit on Windows 64-bit. WOW allows 32-bit applications to run on 64-bit platforms. For example, if an assembly has the 32BitRequired field set, it will run inside the WOW on a 64-bit machine.

Larry Sullivan (Expert):
Q: So how ANYCPU built assembly can detect at load time it will be executed in WOW64 or natively 64bit? Something like IsWow64Process() API but managed?
A: At load time, in Windows, the OS loader checks to see if the image has the COM+ Header. If it does then we check other flags. If it is ILOnly and not marked 32bitrequired then the OS starts a 64bit process for this application. If the machine type is x64 or IA64 then it also starts a 64bit process. If 32bitrequired is set then it starts a 32bit WOW process.

Larry Sullivan (Expert):
Q: So, what would be the benefit to mark an application as AnyCPU/64 when it can be executed as 32-bit, when the 32-bit one would still run in the WOW, and save memory?
A: It is up to you and the type of application is memory intensive then putting more hardware at the problem can help. Say a big database. We are hoping to also enable some scenarios on 64bit like HPC. I would say that AnyCPU is the best option as we are working hard to make sure that these applications have similar performance in Whidbey and it will run as a native application on the platform. But if you have an application that doesn't need 64bit but it is going to run on a 64bit OS then mark it x86.

Larry Sullivan (Expert):
Q: I meant smth like that: if (System.Diagnostics.Process.Current.IsWow64Process == true) then ...
A: We usually use the size of an Int.Ptr, but you can PInvoke out to the OS to find out as well.

Surupa MSFT (Expert):
Q: Are there any changes in GC 64 against GC 32? For example large object min size, generations policy etc.?
A: Yes. The GC is tuned for each individual platform.

Anne MSFT (Moderator):
Q: What is the difference between x86 and IA 64? What does IA stand for?
A: IA stands for Itanium architecture. For information about the Itanium platform, see https://www.microsoft.com/presspass/press/2000/Jul00/ItaniumPR.asp.

Surupa MSFT (Expert):
Q: I read that there is no guarantee on the results arising out of floating point operations on different 64-bit platforms and on 32-bit platform from the same IL - so what’s the solution to this and advice for people developing financial applications ?
A: One should completely avoid code that checks for equality for floating point.

Anne MSFT (Moderator):
Thank you for joining us today on a Microsoft Community Chat to talk about “Managed Code on 64-Bit Windows Platforms.” If you would like further information on this topic please visit the following URL(s):

Top of pageTop of page