Integer Do's And Don'ts

[John Baker]

When declaring an integer, you can specify the size by using int16,
int32, or int64, with plain integer being int32.

Is integer the accepted default in the programming community?

If so, is there a way to remove the ones with size predefined from the
autolisting of types when I am declaring something?
--
To Email Me, ROT13 My Shown Email Address

[Gerald Hernandez]

heh, personal? yeah, hopefully no-one thinks these debates are personal.
one of the great, and IMHO fun things, about these groups are the passionate
discussions between the well informed. many might consider me well informed
as well, but I always learn something new from these debates.

someone needs to "stir the pot" in a manner of speaking. if everyone agreed,
it would be a pretty boring planet.

:-)

Gerald
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Gerald,

I think we are in one line, I have not seen in this thread that Microsoft
people ever told that Integer will "never" be the same as a 64 or a more
bits processor word.

What I have seen stated in this thread a lot of times, however MVP's do not represent Microsoft.

I can assure you I would save that statement when it was a guy from
Microsoft who told that.

And do not see this wrong, it is arguing between regulars in this newsgroup it is not something personal. (Where I am mostly alone against the MVP's,
because I am not a MVP, however that does not shut my mouth so I am glad
with your help).

However in my mind I am sure those regular MVP's from this newsgroup will
support me when it is serious.

:-)

Cor

[Mattias Sjögren]

John,

If so, is there a way to remove the ones with size predefined from the
autolisting of types when I am declaring something?

If you don't import the System namespace it will not show up. A global
import of System is usually set in the project properties, so make
sure you remove that if you want to get rid of them.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Larry Serflaten]

"Gerald Hernandez" <Cablewizard@sp*********@Yahoo.com> wrote

And why not? Aliases like this are common in C.
Hopefully, dotNet will be widely cross platform capable :-)

#If Is64BitSystem Then
Define Integer = Int64
#Else
Define Integer = Int32
#End If <...> I know this is relatively foreign to us long time VB users, but makes sense
to multi-platform developers.

I dunno if it was all that foreign, VB4 had a lot of that going on, where API's
were available in both the 16 and 32 bit flavors, depending on which platform
was being used. Samples posted anywhere had to account for the difference
in platforms that any potential reader (developer) may be using....

;-)
LFS

[Jay B. Harlow [MVP - Outlook]]

Herfried,
This does raise an interesting question. We all seem to be assuming that
there will be a 32-bit compiler & a 64-bit compiler in .NET 2.0. I suspect
there will be a single VB.NET compiler (vbc.exe), as I understand there is
going to be a single 32-bit VS.NET, based on the video I posted or an MSDN
article or MSDN Magazine article.

I know the JIT changes based on what platform is deployed, however as you
already stated, the VB compiler already decided on Int32.

I'm not seeing anything obvious in Beta 1 that would either confirm or deny
a single vbc.exe or 2 vbc.exes (it may be too early in the beta).

The way I understand the 64-bit framework itself working (based on the above
video & various MSDN Magazine articles) is that you simply have an assembly,
this assembly is "agnostic" in that it can run on either 32-bit or 64-bit
framework no problem. Or the assembly will bit bit-centric to handle the
cases where you are calling a 32-bit unmanaged API or a 64-bit unmanaged
API.

Thinking about it, I see no real need for a 32-bit specific compiler (C# or
VB.NET) & a specific 64-bit (C# or VB.NET) compiler, as both would simply
create IL for the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT
as the machine instructions needed change. I also see a need for (parts of)
the runtime assemblies changing, as you may need to call a 32-bit or 64-bit
unmanaged API...

The fact the JIT is creating 32-bit or 64-bit machine code is an
implementation detail, that developers do not really need to worry about...

I'll look around the beta to see what I can find...

Hope this helps
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb:

As Herfried pointed out, on the 64-bit edition of .NET, currently in
Beta.
The definition of VB.NET is the same, hence the above definition is the
same.

I don't have a 64-bit machine. AFAIK, applications compiled against the
32-bit version of the .NET Framework will work without the need to
recompilation on 64-bit versions of the .NET Framework.

The mapping 'Integer' -> 'Int32' is done at compile time. The only way I
see for making 'Integer' to map to 'Int32' is a change in the VB.NET
compiler's behavior. If the compiler was changed to map 'Integer' to
'Int64' on a 64-bit system, then this code won't compile there with
'Option
Strict On', but it will compile with the 32-bit compiler:

\\\
Dim i As Int32 = ...
Dim j As Integer = ...
i = j
///

Consequently, I don't see a chance that 'Integer' will ever map to
'Int64',
because this would cause even more confusion and broken code than the
change
from VB6 to VB.NET caused.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Cor,
One thing I think you are forgetting, that Gerald just reminded me of.

Is that .NET is based on a 'virtual execution system' the CLI (Common
Language Infrastructure), that the CLI insulates .NET programs from the
underlying operating system.

This operating system could be Windows, Linux, or Mac OS. It could be 32-bit
or 64-bit. Which means it could even be an AS/400 or a IBM MainFrame.

In other words the point of the CLI (.NET) is that your program will run on
what ever platform that has .NET available for it...

For details read the "The Common Language Infrastructure Standard" normally
found at "
\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool Developers
Guide\docs" when you install VS.NET 2003.

Hope this helps
Jay

"Cor Ligthert" <no************@planet.nl> wrote in message
news:eD**************@tk2msftngp13.phx.gbl...

Jay,

It is saterday night here so when I make a mistake do not see it to hard,
Herfied knows what that means for me.

Are you attempting to agree with Ken, Herfried, and I? We have all stated
that for Interop, with unmanaged code, we use the explicit types. As
Herfried & I have stated, we do this because the unmanaged sizes might
change.

I do not understand in your statement "Ken" in it, because my fist message
was that I agree with Ken and probably Gerald.

In the situation of interop there is not any discussion at all what I
showed with my statement of comp-3 probably from all the regurlars you and
I are the ones who knows the best what that means. About that point we
have no disagreement at all.

I find Short Integer and Long the most explicit types, that is what I am
telling all the time.

The only thing we disagree is that it is in my opinon 100% sure that
Integer will forever be a 32bits word. There is no need for it as I
thought (because as I stated before I did not investigate that) Gerald
showed that ver well. It can be in a computer that holds a 64bit processor
a disadvantage because there should be a conversion to cut of the first
32bits.

So I think that Integer will be in future a format (set by property or by
default) what will be more normalized to the than used lowest
processortype.

I hope that I stated it well although it is saterdaynight here.

Cor

[Herfried K. Wagner [MVP]]

Jay,

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb:

This does raise an interesting question. We all seem to be
assuming that there will be a 32-bit compiler & a 64-bit
compiler in .NET 2.0. I suspect there will be a single
VB.NET compiler (vbc.exe)
I suspect that too. Only one compiler is needed.
as I understand there is going to be a single 32-bit
VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
article.
ACK. From what I have heard, there will be a 32-bit VS 2005 only.
I know the JIT changes based on what platform is deployed, however as you Thinking about it, I see no real need for a 32-bit specific
compiler (C# or VB.NET) & a specific 64-bit (C# or
VB.NET) compiler, as both would simply create IL for
the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
machine instructions needed change. I also see a
need for (parts of) the runtime assemblies changing, as you
may need to call a 32-bit or 64-bit unmanaged API...
That's what I think too, and that's the reason why I doubt that there will
be a change in the mapping between 'Integer' and 'Int32'.
I'll look around the beta to see what I can find...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Herfried,
I just found this blog "Adventures in the 64bit CLR" in case anyone is
interesting.

http://blogs.msdn.com/joshwil/

Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ok**************@TK2MSFTNGP11.phx.gbl...

Jay,

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb:

This does raise an interesting question. We all seem to be
assuming that there will be a 32-bit compiler & a 64-bit
compiler in .NET 2.0. I suspect there will be a single
VB.NET compiler (vbc.exe)

I suspect that too. Only one compiler is needed.

as I understand there is going to be a single 32-bit
VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
article.

ACK. From what I have heard, there will be a 32-bit VS 2005 only.

I know the JIT changes based on what platform is deployed, however as you

Thinking about it, I see no real need for a 32-bit specific
compiler (C# or VB.NET) & a specific 64-bit (C# or
VB.NET) compiler, as both would simply create IL for
the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
machine instructions needed change. I also see a
need for (parts of) the runtime assemblies changing, as you
may need to call a 32-bit or 64-bit unmanaged API...

That's what I think too, and that's the reason why I doubt that there will
be a change in the mapping between 'Integer' and 'Int32'.

I'll look around the beta to see what I can find...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Herfried,
"vbc /help" in .NET 2.0 beta 1 gives:

/platform:<string> Limit which platforms this code can run
on;
must be x86, x64, Itanium or anycpu
(default).

Which is what http://blogs.msdn.com/joshwil/ suggested C# does.

Within VS.NET (beta 1) you can use "Project - Properties - Compile -
Advanced - Target CPU" to change the above setting.

Compiling the following with Target CPU = Itanium (Intel's 64-bit CPU):

Public Class MainForm

Public Shared Sub Main()
Dim index As Integer = 10
index *= 100
End Sub

End Class

Gives the following IL.
..method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 11 (0xb)
.maxstack 2
.locals init ([0] int32 index)
.language '{3A12D0B8-C26C-11D0-B442-00A0244A1DD2}',
'{994B45C4-E6E9-11D2-903F-00C04FA302A1}',
'{00000000-0000-0000-0000-000000000000}'
// Source File 'C:\Documents and Settings\Jay\My Documents\Visual
Studio\Projects\Windows 64 Application\Windows 64 Application\MainForm.vb'
//000009: Public Shared Sub Main()
IL_0000: nop
//000010: Dim index As Integer = 10
IL_0001: ldc.i4.s 10
IL_0003: stloc.0
//000011: index *= 100
IL_0004: ldloc.0
IL_0005: ldc.i4.s 100
IL_0007: mul.ovf
IL_0008: stloc.0
//000012: End Sub
IL_0009: nop
IL_000a: ret
} // end of method MainForm::Main

Which demonstrates, as I was saying: VB.NET defines Integer as an alias for
Sytem.Int32.

Of course I need a Win64 machine to actually execute the above program :-)
Note: The default of AnyCPU for Platform allows your single executable to
run as a 32-bit app on Win32 & a (full!) 64-bit app on Win64! Which IMHO
reinforces the notion that "Integer is an alias for System.Int32" even on
the 64-bit edition of .NET.
Of course if one really needs a platform specific Int, then one could use a
variation of Gerald earlier post.

Something like:

#If Is64BitSystem Then
Imports Int = System.Int64
#Else
Imports Int = System.Int32
#End If

Public Shared Sub Main()
Dim index As Int = 10
index *= 100
End Sub

Of course then you need to be careful of literals (100I verses 100L) and
public methods into & out of your assembly... (all the pain we learned from
C :-))

Alternatively I would consider defining Int as a structure and overload all
the operators. Then compile 3 versions of the assembly with the Int
structure, one for each Target CPU. Which may introduce its own performance
issues, however like System.IntPtr I would only use Int for Interop...
I'm really not sure why there are 2 64-bit targets (x64 & Itanium). I would
expected only one...

Hope this helps
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ok**************@TK2MSFTNGP11.phx.gbl...

Jay,

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb:

This does raise an interesting question. We all seem to be
assuming that there will be a 32-bit compiler & a 64-bit
compiler in .NET 2.0. I suspect there will be a single
VB.NET compiler (vbc.exe)

I suspect that too. Only one compiler is needed.

as I understand there is going to be a single 32-bit
VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
article.

ACK. From what I have heard, there will be a 32-bit VS 2005 only.

I know the JIT changes based on what platform is deployed, however as you

Thinking about it, I see no real need for a 32-bit specific
compiler (C# or VB.NET) & a specific 64-bit (C# or
VB.NET) compiler, as both would simply create IL for
the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
machine instructions needed change. I also see a
need for (parts of) the runtime assemblies changing, as you
may need to call a 32-bit or 64-bit unmanaged API...

That's what I think too, and that's the reason why I doubt that there will
be a change in the mapping between 'Integer' and 'Int32'.

I'll look around the beta to see what I can find...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Gerald Hernandez]

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
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Os**************@TK2MSFTNGP15.phx.gbl...

Herfried,
"vbc /help" in .NET 2.0 beta 1 gives:

/platform:<string> Limit which platforms this code can run
on;
must be x86, x64, Itanium or anycpu
(default).

Which is what http://blogs.msdn.com/joshwil/ suggested C# does.

Within VS.NET (beta 1) you can use "Project - Properties - Compile -
Advanced - Target CPU" to change the above setting.

Compiling the following with Target CPU = Itanium (Intel's 64-bit CPU):

Public Class MainForm

Public Shared Sub Main()
Dim index As Integer = 10
index *= 100
End Sub

End Class

Gives the following IL.
.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 11 (0xb)
.maxstack 2
.locals init ([0] int32 index)
.language '{3A12D0B8-C26C-11D0-B442-00A0244A1DD2}',
'{994B45C4-E6E9-11D2-903F-00C04FA302A1}',
'{00000000-0000-0000-0000-000000000000}'
// Source File 'C:\Documents and Settings\Jay\My Documents\Visual
Studio\Projects\Windows 64 Application\Windows 64 Application\MainForm.vb'
//000009: Public Shared Sub Main()
IL_0000: nop
//000010: Dim index As Integer = 10
IL_0001: ldc.i4.s 10
IL_0003: stloc.0
//000011: index *= 100
IL_0004: ldloc.0
IL_0005: ldc.i4.s 100
IL_0007: mul.ovf
IL_0008: stloc.0
//000012: End Sub
IL_0009: nop
IL_000a: ret
} // end of method MainForm::Main

Which demonstrates, as I was saying: VB.NET defines Integer as an alias for Sytem.Int32.

Of course I need a Win64 machine to actually execute the above program :-)
Note: The default of AnyCPU for Platform allows your single executable to
run as a 32-bit app on Win32 & a (full!) 64-bit app on Win64! Which IMHO
reinforces the notion that "Integer is an alias for System.Int32" even on
the 64-bit edition of .NET.
Of course if one really needs a platform specific Int, then one could use a variation of Gerald earlier post.

Something like:

#If Is64BitSystem Then
Imports Int = System.Int64
#Else
Imports Int = System.Int32
#End If

Public Shared Sub Main()
Dim index As Int = 10
index *= 100
End Sub

Of course then you need to be careful of literals (100I verses 100L) and
public methods into & out of your assembly... (all the pain we learned from C :-))

Alternatively I would consider defining Int as a structure and overload all the operators. Then compile 3 versions of the assembly with the Int
structure, one for each Target CPU. Which may introduce its own performance issues, however like System.IntPtr I would only use Int for Interop...
I'm really not sure why there are 2 64-bit targets (x64 & Itanium). I would expected only one...

Hope this helps
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ok**************@TK2MSFTNGP11.phx.gbl...

Jay,

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb:

This does raise an interesting question. We all seem to be
assuming that there will be a 32-bit compiler & a 64-bit
compiler in .NET 2.0. I suspect there will be a single
VB.NET compiler (vbc.exe)

I suspect that too. Only one compiler is needed.

as I understand there is going to be a single 32-bit
VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
article.

ACK. From what I have heard, there will be a 32-bit VS 2005 only.

I know the JIT changes based on what platform is deployed, however as

you

Thinking about it, I see no real need for a 32-bit specific
compiler (C# or VB.NET) & a specific 64-bit (C# or
VB.NET) compiler, as both would simply create IL for
the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
machine instructions needed change. I also see a
need for (parts of) the runtime assemblies changing, as you
may need to call a 32-bit or 64-bit unmanaged API...

That's what I think too, and that's the reason why I doubt that there will be a change in the mapping between 'Integer' and 'Int32'.

I'll look around the beta to see what I can find...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

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...timization.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@sp*********@Yahoo.com> wrote in message
news:%2******************@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>>

[Gerald Hernandez]

Jay,

<...>

I would expect P/Invoke to be largely agnostic also <...> In other words I can understand platform = 32bit or 64bit or Any, I just
haven't seen the explanation on why both x64 & Itanium...
Ah, good point. That is supposed to be the beauty of .Net in the first
place! I'll keep my eyes open for some sort of better explanation. Might be
interesting. Got out of the server business shortly before the buzz of x64.
Didn't sell many Itanium servers. Customers would buy like 4-32bit Linux
boxes and got better overall throughput for a whole LOT less money.

You have the 80/20 rule mapped to a AutoText or something? ;-)
But it is spot on and worth repeating.
Haven't looked at the Beta stuff yet. Maybe I should get up to speed.

Gerald
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OV*************@TK2MSFTNGP09.phx.gbl... 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...timization.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@sp*********@Yahoo.com> wrote in message
news:%2******************@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>>

[Josh Williams [MS]]

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...timization.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@sp*********@Yahoo.com> wrote in message
news:%2******************@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>>