Re: Integer Do's And Don'ts

From: Josh Williams [MS] (joshwil_at_-nospam-microsoft.com)
Date: 10/19/04 

Date: Tue, 19 Oct 2004 09:01:08 -0700

Reply to earlier topic on this thread:
IL contains a native int type which is surfaced in managed languages as
System.IntPtr; that type has integer semantics and will be 8-bytes on a
64-bit machine and 4-bytes on a 32-bit machine (IntPtr.Size is a static
property which can be used to cheaply determine bitness programatically).

As for why there are X64 and Itanium options?
An answer (not the only one, but a good one) is P/Invoke. If you're
P/Invoke-ing out to a OS provided DLL you can be pretty sure that it will
exist on both IA64 and X64 platforms... But, if you have some native code
from somewhere else that you need to P/Invoke to and you want to ship it with
your product say; then you need to make sure to include both IA64 and X64
versions if you want your app to run on both platforms. What if the vendor
who wrote the component didn't provide both versions, or didn't bother
compiling both versions (it is worth noting that native IA64 code is
significantly harder to write than X64 code, and there isn't nearly as much
IA64 penetration in the marketplace as there will be with both AMD and Intel
X64 systems now out)?

Thus we allow you to bind your app to a single 64-bit platform. If you
compile your app with /platform:anycpu then it will run under 64-bits on a
64-bit machine which is more or less what you want. The only case I can
imagine where you might want a more generic 64-bit only marking would be for
unsafe code that is compiled to be 64-bit specific (but not platform
specifc)... In that case most of the bitness specific code is around pointer
sizes and using proper pointer types in C# will let you avoid that... I don't
even think that you can use straight pointers in VB so the point is moot.
Even so, you could concievably write your code with an if (IntPtr.Size == 4)
{ /* 32-bit code */ } else { /* 64-bit code */ }. As IntPtr.Size is a static
property which is hardcoded by the runtime to be 4 or 8 depending on the
platform a smart JIT (which I believe ours to be) should be able to inline it
and use its dead code eliminator to throw away the non-executed half of the
conditional as well as the conditional statement itself.

"Jay B. Harlow [MVP - Outlook]" wrote:

> Gerald,
> > I haven't paid much attention to the x64 vs Itanium stuff. But as I
> > understand it, the x64 is kind of a hybrid processor. It has the 32 Bit
> > instructions as well as the 64 Bit instructions.
> I believe you may be correct. However! VB.NET & C# compiles down to IL, IL
> is platform agnostic. As far as I know the only real reason you need to know
> the platform is P/Invoke (the marshaller needs to know how to package the
> parameters).
>
> I would expect P/Invoke to be largely agnostic also, in that its just a
> Thunk to the real API. In other words the JIT &
> System.Runtime.InteroprServices class resolve any calling convention
> differences, the IL is an abstraction that shouldn't care if you are a
> hybrid process or not...
>
> In other words I can understand platform = 32bit or 64bit or Any, I just
> haven't seen the explanation on why both x64 & Itanium...
>
> > Gotta watch out how much memory we consume.
> Just Remember the 80/20 rule. That is 80% of the execution time of your
> program is spent in 20% of your code. I will optimize (worry about
> performance, memory consumption) the 20% once that 20% has been identified &
> proven to be a performance problem via profiling (CLR Profiler is one
> profiling tool).
>
> For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
> article "Yet Another Optimization Article" at
> http://martinfowler.com/ieeeSoftware/yetOptimization.pdf
>
> > Would be a shame to waste half of it due to unneccessary boxing.
> Unnecessary boxing can be a bad idea even in the 32-bit world! Which is why
> the new Generic collection classes
> (http://msdn2.microsoft.com/library/0sbxh9x2.aspx) will be very handy
> indeed. I normally try to apply the 80/20 rule on deciding if I want to use
> an array of value types or an Arraylist of value types. With .NET 2.0 & the
> Generic collection classes I may simply favor the Generic collection
> classes, unless they, via profiling are shown to be a performance issue for
> a specific routine...
>
> Hope this helps
> Jay
>
>
>
>
> "Gerald Hernandez" <Cablewizard@spam_remove@Yahoo.com> wrote in message
> news:%23TkML%23LtEHA.3412@TK2MSFTNGP14.phx.gbl...
> > Thanks, that is a good read.
> > While I hadn't really considered Integer being Int64 on 64 bit processors
> > in
> > the near future, it does look like there are some things to consider. It
> > does look like 2 Int32's will be packed nicely into an Int64, which we all
> > would expect now. This is a nice change from past platform differences
> > where
> > a whole Int64 might be allocated for 1 Int32. Guess we need to be aware of
> > the size of the pointers, which we also knew, but looks like it could
> > raise
> > it's head in unexpected ways. Gotta watch out how much memory we consume.
> > Would be a shame to waste half of it due to unneccessary boxing.
> >
> > I haven't paid much attention to the x64 vs Itanium stuff. But as I
> > understand it, the x64 is kind of a hybrid processor. It has the 32 Bit
> > instructions as well as the 64 Bit instructions. Also supports both memory
> > pipelines. The Itanium has it's own set of 64 Bit instructions, and only
> > those. So in the long run it looks like it might die due to compatibility
> > issues.
> >
> > Gerald
> >
> >
> <<snip>>
>
>
>

Quantcast