Gaurav Seth's WebLog : Tech - VS, .NET etc

MSDN webcasts on 64-bit platform computing

GauravS — Tue, 25 Apr 2006 12:10:00 GMT

Here are some really cool MSDN webcasts related to 64-bit computing. If you are getting started with 64-bit platforms or want to know a lot more about them, I am sure you would find these to be useful.

· MSDN Webcast: Welcome to 64-bit Windows Computing: Introduction, Architecture, Roadmap and 32-bit Application Compatibility (Level 100)

· MSDN Webcast: Terminal Services: Clear-cut Benefits with Windows Server 2003 x64 (Level 300)

· MSDN Webcast: Taking Application Development to the Next Level: Design and Development for 64-Bit Windows (Level 300)

· MSDN Webcast: Migrating Your Code to Run Natively on 64-Bit Windows: Insider Tips and Indispensable Tools (Level 300)

· MSDN Webcast: Managed Code on 64-bit Windows Platforms (Level 300)

· MSDN Webcast: Making the Most of Enterprise Hardware: SQL Server 2005 Data Transformation Services (Level 200)

· MSDN Webcast: Kernel Mode Drivers in Windows 64-bit Systems: Migration and Development (Level 300)

· MSDN Webcast: Implementing Security for Mobile Device Solutions (Level 200)

· MSDN Webcast: Guest Presenter: AMD64 Architecture Drilldown: 64-bit Performance and 32-bit Compatibility (Level 400)

· MSDN Webcast: Going Native on 64-bit Windows Platforms: Code Optimization Tools and Techniques (Level 300)

· MSDN Webcast: Going Native on 64-bit Windows Platforms: Application Support and Migration from Existing Application Frameworks (Level 300)

· MSDN Webcast: Data Warehousing with SQL Server 2000 Enterprise Edition (64-bit) (Level 300)

· MSDN Webcast: Active Directory: Maximize Performance in Enterprise Deployments with Windows Server 2003 x64 (Level 300)

· MSDN Webcast: 64-bit Computing with Intel(r) Processors - Enabling the Future (Level 400)

· MSDN Webcast: .NET Compact Framework 2.0 (Level 100)

· MSDN Architecture Webcast: Developing Applications for Windows XP x64 Edition with Visual Studio 2005 (Level 200)

In case I have missed some and you know of more, let me know.

Floating points - IEEE-754 Floating Point numbers

GauravS — Mon, 24 Apr 2006 15:48:00 GMT

I found these blog entries from Prem to be quite exhaustive. So posting the links here just in case you would want to know more …

What is WoW, Windows on Windows, WoW64, WoWx86 emulator … in 64-bit computing platform

GauravS — Mon, 24 Apr 2006 15:21:00 GMT

Before we discuss this, it is important for the users to understand a few facts about 64-bit platform offerings.

64-bit computing (from a Microsoft perspective) comes in two variants

· x64 (EM64T/AMD64)

· Itanium (EPIC)

Both, Windows Server 2003 SP1 64-bit and Windows XP 64-bit, support the above two mainstream 64-bit processor architectures.

Code execution is enable in both the above kind of platforms in two ways

· Native 64-bit

· WoW64 x86 emulator

While as the name implies, native 64-bit takes advantage of the native 64-bit computing platform, Windows-On-Windows environment, WoW, WOW64 etc. are all names that refer to an x86 emulator that allows 32-bit Windows-based applications to run on 64-bit Windows. Wow64 allows 32-bit productivity applications developed using the .NET Framework 1.0, 1.1 and 2.0 and Win32 to run on 64-bit Windows and take advantage of the 64-bit Windows kernel which offers a larger number of kernel handles and window handles. WoW64 supports 32-bit console, GUI and service application, and although some 32-bit server applications may be certified to run on WoW64, WoW64 is NOT intended for 32-bit server apps. WoW64 does NOT support 16-bit Windows apps.

WoW64 emulation is performed natively (on the chip) by the x64 micro-architecture, which means WoW64 performance on x64 is similar to that of 32-bit Windows. However, because the Itanium (IA64) architecture does not support native WoW64 emulation, WoW64 performance on the Itanium is substantially less than that of 32-bit Windows.

64-bit Visual J# Redistributable TAP goes live

GauravS — Mon, 03 Apr 2006 12:14:00 GMT

If you have been reading my blogs and wondering that why off late I have been discussing a lot of advantages, issues and other stuff related to 64-bit computing – here is the answer. All this while (since the Whidbey release) the Visual J# team has been working on enabling the language for 64-bit platforms.

Today, we have officially opened the Technology Adoption Program (TAP) with select customers and MVPs for 64-bit Microsoft Visual J# Redistributable today. This program would run through June’06.

With the 64-bit Microsoft Visual J# Redistributable now available, J# users can now leverage

• Existing 64-bit workstation and server infrastructure investments

• Existing 64-bit .NET Framework investments

Catch you soon with more!!!

Dual Core Vs Dual Processor Vs Hyper Threading

GauravS — Mon, 20 Mar 2006 17:13:00 GMT

As we start talking of high performance computing, 64-bit platform offerings etc. some of the buzz words that come into play are dual processor, dual core and Hyper Threading. I thought it would be a good idea to find and write about what these technologies are all about, who fares where and what is the best.

While the Dual-core systems refers to having a CPU that includes two complete execution cores per physical processor, a Dual-processor (DP) systems is one which contains two separate physical computer processors on the same chassis. Unlike dual processors systems where the two procs can be located on the same motherboard and at times on separate boards, in Dual Core, one integrated circuit contains two complete computer processors. In the Dual core systems, there is a combined cache and the controller between the two processors, it is independent in dual processor systems. The Advanced Programmable Interrupt Controllers (APIC) in both these cases are separate for each processor, providing multi processor interrupt management.

Hyper Threading (HT) technology was developed by Intel and is somewhere midway between the above two. In HT enabled systems, the circuitry enables one physical processor to appear as two logical processors. This enables a separate APIC for each logical processor while maintaining a single cache.

As they say a picture speak louder than a thousand words, here is the picture of what I described above.

I would more about these, there pros and cons etc. in some of my next blogs.

Some interesting reads on 64-bit performance benchmarks

GauravS — Mon, 20 Mar 2006 12:47:00 GMT

Here are some of the sites that I have really found good and informative about the different performance reports for 64-bit platforms (from a MS technology centric perspective).

64-bit Performance Benchmark: .NET 2.0 and IBM Websphere 6.0 - http://msdn.microsoft.com/vstudio/java/compare/benchmark64/default.aspx

XML performance showdown: Java, Mono and .NET - http://www.process64.com/articles/xmlmark1/xml-mark-revisited.pdf

Performance figures for 64-bit Paint.NET v2.6 - http://paintdotnet.12.forumer.com/viewtopic.php?t=651

Demo of the paint.NET application on different platforms

http://www.eecs.wsu.edu/paint.net/misc/PDN_x86_vs_x64.zip

Performance comparison of Java (and .NET) runtimes - http://gcc.gnu.org/ml/java/2004-10/msg00099.html

HPC.NET – are CLI based Virtual Machines Suitable for High Performance Computing - http://www.sc-conference.org/sc2003/paperpdfs/pap251.pdf

In case you know of more, pl share the same.

Moving from 32-bit to 64-bit application development on .NET Framework

GauravS — Tue, 07 Mar 2006 10:12:00 GMT

This blog aims at clarifying the issues which 32-bit developers might be having when they start migrating to the 64-bit platform. My observations below would be concentrated towards the .NET Framework related technologies. Most of the things I discuss below are available at various scattered places. I am just aiming at collecting them at a single place to help developers migrating to the 64-bit platform.

Size of the Redist

As compared to the pure 32-bit platform offerings, the 64-bit offerings are usually double the size. This means the time to download and setup the 64-bit .NET Redistributable or anything similar also increases. But the reason for the same is the fact that the 64-bit offerings come clubbed with the 32-bit offerings. It enables applications to run in the native 64-bit mode as well as the WoW64 mode (which is the 32-bit version).

Framework64 directory

Unlike the 32-bit .NET Framework, when a user installs a 64-bit Redist on the machine there are two Framework directories that get created. They are

· …\WINDOWS\Microsoft.Net\Framework\v2.0.50727

· …\WINDOWS\Microsoft.Net\Framework64\v2.0.50727

Notice the difference in the two directories. The Framework directory contains the assemblies that are specific to the WoW64 (32-bit emulation on 64-bit platforms) world. The Framework64 directory on the other hand contains assemblies that are specific to the 64-bit platform. And assemblies that are platform agnostic are available in either or both the directories as per need basis.

Creating platform specific apps

Most of the language compilers (like C#) now offer a /platform switch. By using this switch, developers can create binaries targeted for a specific platform type or binaries that are platform agnostic. There are four types of binaries that are emitted

· anycpu – platform agnostic

· x86 – 32-bit platform specific

· x64 – x64 platform specific

· itanium – IA platform specific

(Read more about x64 and IA – their differences, similarities and FAQs here)

By default the compilers (like C#) emit anycpu binaries (also called portable assemblies) which are platform agnostic. In case the users want to create binaries specific to a platform, they can use the appropriate switch and be done.

Cross Compilation

The above concept of /platform switch enables cross compilation of binaries. Cross compilation means compiling binaries to a specific platform type (different from the current platform). This is mostly used in terms of compiling and creating 64-bit assemblies from a 32-bit compiler and vice versa. One point to note here is that cross compilation usually refers to compiling to different target types from the compilers shipped with the 64-bit Redist (WoW and 64-bit). The reason for this is that, while trying to compile for a 64-bit platform from a pure 32-bit machine, the 32-bit Redist would not have the components that are 64-bit specific. In such cases the compilation might go through with warning but execution might lead to runtime exceptions. Also, one should note that while cross compiling, users should stick to the platform architecture type of the machine, viz. x64 or IA. Assemblies for IA and x64 are specific to the platform architecture and cross compilation across architectures is not advised.

GAC in 64-bit platforms

Now, that we know that there are multiple types of assemblies and ways to create specific assembly types, the question comes about the Global Assembly Cache (or GAC) in the 64-bit machines. Unlike the .NET Framework 1.1, where the 32-bit specific offerings used to have a single GAC present the model has changed for .NET Framework 2.0 (Whidbey). There are 3 types of GAC’s now available

· GAC_32

· GAC_64

· GAC_MSIL

While the 32-bit platforms have GAC_32 and GAC_MSIL, the 64-bit have all the three. GAC_32 contains assemblies that are specific to the 32-bit platform and GAC_64 specific to the 64-bit platform. The GAC_MSIL contains the assemblies that are platform agnostic. While trying to load assemblies from the GAC, the CLR first looks at the GAC specific to the platform. If it is unable to find the same, it then moves to the GAC_MSIL.

Apart from these, we also have the conventional GAC present in all platforms which homes the .NET 1.0/1.1 assemblies which are platform independent.

Corflags demystified

Corflags.exe is a tool that is shipped as a part of the .NET Framework SDK. It is a powerful tool which allows users to view and configure the corflags section of a PE image. All the data related to platforms is available in this part of the PE image. Let us view the options available from this tool.

C:\WINDOWS\assembly\GAC_32>corflags /?

Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 2.0.50727.42

Usage: Corflags.exe Assembly [options]

If no options are specified, the flags for the given image are displayed.

Options:

/ILONLY+ /ILONLY- Sets/clears the ILONLY flag

/32BIT+ /32BIT- Sets/clears the 32BIT flag

/UpgradeCLRHeader Upgrade the CLR Header to version 2.5

/RevertCLRHeader Revert the CLR Header to version 2.0

/Force Force an assembly update even if the image is

strong name signed.

WARNING: Updating a strong name signed assembly

will require the assembly to be resigned before

it will execute properly.

/nologo Prevents corflags from displaying logo

/? or /help Display this usage message

A look at an example of a PE header seen from this tool for a 32-bit assembly is below

Version : v2.0.50727

CLR Header : 2.5

PE : PE32

CorFlags : 11

ILONLY : 1

32BIT : 1

Signed : 1

Here is what each component of the header means

Version: Contains the version of .NET Redist with which the binary is built.

CLR Header: 2.0 indicates a .Net 1.0 or .Net 1.1 (Everett) image while 2.5 indicates a .Net 2.0 (Whidbey) image.

CorFlags: This is computed by OR’g specific flags to indicate whether the image is ILONLY, its bitness etc. and is used by the loader.

ILONLY: Managed images are allowed to contain native code. To be “anycpu” an image shall only contain IL.

32BIT: Even if you have an image that only contains IL it still might have platform dependencies, the 32BIT flag is used to distinguish “x86” images from “anycpu” images. 64-bit images are distinguished by the fact that they have a PE type of PE32+.

The most interesting aspect is the PE and the 32BIT flag of the header. These combine to specify the assembly types. Here is how they would look like for:

· anycpu: PE = PE32 and 32BIT = 0

· x86: PE = PE32 and 32BIT = 1

· 64-bit: PE = PE32+ and 32BIT = 0

Using corflags tool, users can forcefully change the PE headers of any assembly to make them behave the way they want to. Users can force most of the flags to the values as wanted. However, it is advised to use compiler switches instead of this tool to create binaries with specific characteristics as desired.

64-bit Design Considerations

Apart from what all I have discussed above, there are surely some design considerations that users need to take care of while creating applications for 64-bit/agnostic platforms. These are discussed pretty well in the whitepaper here. So I would not go and re-invent the wheel.

Other helpful resources

· 64-bit Windows

· Getting Started with the 64-Bit .NET Framework

· The x64 Vs AMD64 Vs EM64T Vs Itanium Riddle – What is what?

Other related blogs

· http://blogs.msdn.com/gauravseth/archive/2006/02/17/534128.aspx

· http://blogs.msdn.com/gauravseth/archive/2006/02/21/536079.aspx

· http://blogs.msdn.com/gauravseth/archive/2006/03/02/542055.aspx

· http://blogs.msdn.com/gauravseth/archive/2006/03/06/544637.aspx

Cross compilation in the 64-bit .NET Framework world for platform specific features

GauravS — Mon, 06 Mar 2006 21:20:00 GMT

In today’s world, a lot of applications are written targeting both the 32-bit and/or the 64-bit platform. Using cross compilation, users can now create applications using the .NET Framework which are platform agnostic. This is achieved by the data in the PE header maintained for each app in the .NET Framework world.

Compilers like that of C# and C++ language use the /platform switch to empower the user to choose the platform type, they want their binaries to be executed on. Using this switch the users can just compile their binaries to be anycpu binaries – which implies that they are platform agnostic and execute natively on the 32-bit and the 64-bit platforms. This also enables users to compile binaries specific to a targeted platform – be it x86, x64 or the itanium platform.

This looks to be a perfect solution for compilation of binaries that do not have any feature dependencies on platform specific architectures. Now, lets take a hypothetical scenario where a language supports some features that are 32-bit specific and some features that are platform agnostic. In such cases how should the compiler behave? Here is description of the way I feel applications should be targeted in such cases

Compilation from	Anycpu	X86	X64	IA64
32-bit compiler on a 32-bit machine	Invokes the 32-bit compiler	Invokes the 32-bit compiler	Error	Error
32-bit WoW compiler on a 64-bit machine	Invokes the 64-bit compiler as another process and compiles using the same	Invokes the 32-bit compiler	Invokes the 64-bit compiler as another process and compiles using the same	Invokes the 64-bit compiler as another process and compiles using the same
64-bit compiler	Invokes the 64-bit compiler	Invokes the 32-bit compiler as another process and compiles using the same	Invokes the 64-bit compiler	Invokes the 64-bit compiler

Apart from the compiler, the users should also be aware of the compiler they are compiling from and the targeted scenarios. For e.g. Let us consider an application which is dependent of features not supported in the 64-bit world. The user compiles the same to a binary of the type anycpu from a 32-bit machine. The user then tries to execute the same binary on a 64-bit machine. In most of the cases the user is bound to run into issues and a Bad Format Exception might be thrown. Thus, it is not true that in all scenarios, cross compilation always works.

In case you believe that there is some other way, let me know too.

Executing applications/scripts at User Log-on on Windows XP and Windows 2003 Server

GauravS — Thu, 02 Mar 2006 16:59:00 GMT

I wanted to execute a script/application on my comp when a user logs on to adjust some of the settings specific to the user. I did not know how to go about it and had to scratch a little bit to find how I could achieve the desired result. I am posting it here, so that it is useful for others who might need to do something similar.

It is fairly simple:

Just go to the registry entry

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Create a new key of Type String Value. The value of this key should point to the path of the application/script that you want to execute.

Bingo!!! You have just set-up an application, which would execute each time any user logs on to a machine.

Are you aware of any other ways in which a user can do this?

64 bit technology, Processors, Operating Systems available today

GauravS — Thu, 02 Mar 2006 16:10:00 GMT

There are a whole lot of names by which the 64-bit technology is famous. I just wanted to get a comprehensive list of the same available at one place for my own use. Here is what I found out when I searched for the various names/technologies/OS’s available in the 64-bit arena. The following are the findings

Technology Names

· x64 (Extended 64)

· AMD 64

· EM64T

· Itanium

· RS/6000 64-bit solution from IBM

· Power PC architecture from IBM

· PowerPC 970xx Processors from IBM

· x86-64 for porting open source software to the AMD64 architecture

· 8.1.2 x86 64-bit processors

Processors

AMD64 based

EMT64T based

IA-64 based

· Intel Itanium 2 Processor

Power PC

· Power Mac G5 with PowerPC processors from Apple

SPARC based

· UltraSPARC T1 processor from Sun

· UltraSPARC IV+ 64-bit processor from Sun

PA-RISC technology based

· 64-bit PA-RISC based processors

· 64-bit HP EV68 and EV7 Alpha processor

DEC Alpha Architecture based

· DEC Alpha or Alpha AXP by Digital Equipment Corp. (Compaq)

Operating Systems

· Windows XP x64

· Windows Server 2003 x64

· Solaris 8

· Mac OS X Tiger

· HP-UX operating system

· Tru64 UNIX

· Comprehensive summary of all OS's from AMD

I am sure that while compiling the above, I might have missed some names. In case you are aware, pl comment and help me add to my list.

Thanks.

The x64 Vs AMD64 Vs EM64T Vs Itanium Riddle – What is what?

GauravS — Wed, 01 Mar 2006 18:14:00 GMT

While I tried to learn more about the 64-bit processors, here is what I found out. There are two different sets of architectures present in the world today. The first is called the x64 architecture processors, which is based on the AMD64 and/or Extended Memory 64 Technology (EM64T) as the case of manufacturer may be. The other one is the Itanium processors, which is based on the Explicit Parallel Instruction Computing (EPIC). Nice terms right? Lets try to demystify these. Here is what I found about them.

The x64 platforms in 64-bit computing are offered by two main vendors – AMD and Intel.

AMD64 – AMD64 is AMD’s 64-bit platform that extends the industry-standard x86 instruction set architecture and defines a new class of computing. The AMD64 platform is the first designed to deliver full compatibility with existing x86 solutions and world-class 64-bit performance. To read more FAQs about the AMD64 technology go here. As of now, there are three ranges of processors that AMD offers which use the AMD64 technology
• AMD Opteron processor for servers and workstations
• AMD Athlon 64 processor for desktops and notebooks
• AMD Turion 64 mobile technology for notebooks

I do not want to go into the details of each type right now. In case you are interested AMD’s website might just be the best place for you to search more.

Extended Memory 64 Technology (EM64T) – The Extended Memory 64 Technology is Intel’s enhancement to its IA-32 architecture. The enhancement allows the processor to run newly written 64-bit code and access larger amounts of memory. These extensions do not run code written for the Intel Itanium processor. To read more FAQs about this technology, go here. As of now, there are these three ranges of processors that Intel offers which use the EM64T technology
• Intel Pentium D processor
• Intel Pentium processor Extreme Edition
• Intel Xeon processor

Interestingly enough, while searching, I found a site which states that Intel has commented that EM64T and AMD64 are the same, practically; apart from the differences – well I found this funny. Is everything not the same except for the differences??? :) :) Here is the comment that I got from the site "Even though the hardware micro-architecture for each company's processor is different, the operating system and software ported to one processor will likely run on the other processor due to the close similarity of the instruction set architectures".

The IA platform in 64-bit computing is offered by Intel.

Itanium- The Itanium Processors moves users beyond proprietary Reduced Instruction Set Computer (RISC) architecture. This platform is based on the Explicitly Parallel Instruction Computing (EPIC) architecture. Now what is EPIC? EPIC is a 64-bit microprocessor instruction set, jointly defined and designed by Hewlett Packard and Intel. To read more about it, read here. As of now, Intel offers the Intel Itanium 2 Processor supporting this technology.

Well, hope this was a good summary and a nice set of links to read through!!

But wait a minute. I forgot to discuss what is x64. x64 is Microsoft's generic designation for the Advanced Micro Devices AMD64 and Intel EM64T 64-bit Instruction Set Extensions to the x86 architecture. It stands for Extended 64.

More later ... !

Is 64-bit a superior platform as compared to the 32-bit platform?

GauravS — Tue, 21 Feb 2006 18:35:00 GMT

A lot of people, from different walks of life meet me and often ask, that now, with the availability of 64-bit platforms, should they only go and buy 64-bit machines? Is the 32-bit platform not old and slow? With the availability of 64-bit platforms they feel that there is no point in going ahead and investing in 32-bit technology.

I too, may be also shared similar point of views as theirs till sometime back. This was before I got down to the nitty-gritty’s of the 64-bit system and actually started testing and exploring stuff for myself. The observations that I had were quite revealing. And in the end, many a times were even logical. Though there are quite a few people/organizations who have been independently doing studies and publishing results, I feel for a common man, we are still way to go. A lot needs to be done before everyone including a layman can understand the 64-bit technology and its associated pros and cons.

64-bit platforms, as people make it sound, is not like a fashion range which people should want to own and flaunt. It’s all about a change in perspective. Okie, I would cut across this debate and just focus about a few findings that I saw in the 64-bit platform.

What runs faster on 64-bit?
Applications which perform better on 64-bit platform are usually those which are
• More math intensive – Need more calculations, more floating point precisions,
• More memory address – Need more data to be kept in memory rather than disk at any given time
• More concurrent users or threads

What runs slower on 64-bit?
• Some applications do not perform well on 64-bit platforms because they use more memory and blow out the available cache. The reason for this is larger object reference sizes. Most of the managed world deals with lot of object references.
• Applications which are unable to make full use of the 64-bit processor are slower.
• Startup times of apps is usually more as compared to the 32-bit versions

Where each platform stands -
x64 Native
Performance of the native x64 platform is usually the best amongst all (including x86).
Itanium Native
Performance of native IA64 platform is usually not as good when compared to the x86 platform.
x64 WoW64
The x64 WoW64 scenarios are often found to perform equivalent or better than the x86 scenarios as the kernel can handle tasks in a more efficient way.
Itanium WoW64
Being an emulation of the x86 platform, the Itanium WoW64 is known to have quite a few issues. Problems like getting locked down to a single thread instead of multithreading are common in IA64 WoW scenarios.

Is 64-bit platform always better than 32-bit?

GauravS — Fri, 17 Feb 2006 18:32:00 GMT

I recently did some preliminary performance testing on the 64-bit platform Vs that on 32-bit. Here are the results of the same

	Calculation Speed (milliseconds)			Memory Copy (milliseconds)
Measure	*x86*	*x64*	*IA64*	*x86*	*x64*	*IA64*
Iterations
100000	5.51	0.31	0.7
1000000	59.73	7.64	15.5
10000000	594.74	68.38	150.5
100000000	5822.93	1100.83	1568.84
Memory
512KB				1.1	0.62	1.3
1MB				2.02	0.62	3.6
32MB				74.21	8.1	103.9
64MB				154.61	79.42	181.2
128MB				331.55	154.66	456.6
256MB				660.01	303.92	915.42
512MB				25931	6421.32	19302.94

Note: In order to get stable results for the performance tests, the results as above are averaged of around 100 executions on each platform for each kind of operation.

The iterations for Calculation Speed were performed on the IL instruction set
IL_0060: ldloc.0
IL_0061: ldloc.2
IL_0062: mul
IL_0063: ldc.i4 0x2ab9274a
IL_0068: conv.i8
IL_0069: div
IL_006a: stelem.i8
which corresponds to a calculation between variables and storing the result in an array of type long[]. (myArr1[i] = ((var1 * var3) / 716777290))

The Memory Copy operation included copy between two arrays with the following IL instruction set
IL_008a: ldelem.i8
IL_008b: stelem.i8
which corresponding to copying from one array to another. (myArr2[i] =myArr1[i])

Observations
• Both x64 and IA 64 platforms have a definite improvement in the calculation speed when compared to the x86 platform by as much as 5.3 times and 3.7 times respectively.
• Memory access and copying operation for sizes equal to and lesser than 256MB was most efficient on x64 platform, followed by x86 and then IA64. This is an anomaly in the sense that IA64’s performance was not even as good as x86 platform. While x64 platform was faster than x86 platform by 2.1 times, the IA64 was slower by around 0.67 times.
• Memory access and copying operation for 512MB was most efficient on x64 platform, followed by IA64 and then x86. x64 was around 4 times faster than x86 platform and IA 64 was faster by around 1.34 times when compared to x86 platform.

Machine Configuration:
The machines that I used for this testing had the following configurations
• x86 machine: 1 GB RAM on a 2 GHz machine
• x64 machine: 1 GB RAM on a 2.8 GHz machine
• IA64 machine: 1GB RAM on a 997 MHz machine

Though the above data suggests some performance improvement in 64-bit as compared to the 32-bit, a lot more needs to be done in terms of standardization and acceptance of what works better and what does not on 64-bit-bit platforms when compared to the 32-bit platform.

There are certain known areas where 64-bit platform does not do too well.

So the above observations and findings from my side are not complete enough to be able to announce one of the two platforms as a winner. There is still a lot more that I should and would be doing to find out more.

I would cover that and much more about this topic in my next few blogs. So in case, you are interested - stay connected.

But, the best would be to share your experiences with all. So looking ahead to hear back from the enthusiasts.

Customizing Menu Options in Visual Studio

GauravS — Thu, 16 Feb 2006 18:51:00 GMT

This is one of the cool features that is offered in Visual Studio 2005. I came across this recently, when one of our customers was unable to find the location of the Java Language Conversion Assistant in the normal File -> Open -> Convert... menu of Visual Studio. When I dug deeper into the same here is what I observed.

Visual Studio 2005 Team Edition comes with 7 options as the default settings which a user can choose. They are
1. General Development Settings
2. Team Test Settings
3. Visual Basic Development Settings
4. Visual C# Development Settings
5. Visual C++ Development Settings
6. Visual J# Development Settings
7. Web Development Settings

When a user starts Visual Studio for the first time, Visual Studio prompts the user to select one of these settings and makes it the default setting for that system. The default menu options for the various Visual Studio menu choices are different for the different settings that a user chooses as default for Visual Studio.

The JLCA tool can be accessed from all but the following settings from the above menu
1. Visual Basic Development Settings
2. Web Development Settings

The normal way to access JLCA from Visual Studio is

This enables the user to reach the dialogue box as shown below to access the JLCA tool

Choosing JLCA in this dialogue box launches the JLCA Wizard where-in a user can feed in the options for converting the Java/VJ++ source code to C#.

For the two settings where JLCA cannot be accessed from the above option, here are the two ways to launch the same:

1. Customizing the Menu Option
2. Changing the default settings for Visual Studio

The way a user can customize the Menu Options in Visual Studio is as follows:

Suppose we are in the Visual Basic (or any other) Visual Studio setting
Goto Tools -> Customize

In the Customize dialog box, goto Commands, choose File

Click on Rearrange Commands… button, choose Add, goto File, choose the Convert Command and click OK

This would add the Convert... option in the File Menu. The File menu item now look like this

The way a user can change the default user settings is shown below

Goto Tools->Import And Export Settings...

Choose "Reset All Settings" and click Next

In case you want to save your current settings, save as appropriate. Or else, choose to reset settings overwriting the current settings

This would let you choose one of the possible 7 default settings. Choose the wanted setting and click Finish.

Hope this helps you :)

Accessing Java Objects from within C#

GauravS — Fri, 23 Dec 2005 11:31:00 GMT

We often hear back from customers regarding this interesting problem. I am just throwing a perspective on this. Here is what we heard from one of our customers:

I'm trying to get my organization to move to C# as the primary development tool, but I have to work with another group who insists on using Java. This other group already has a number of large objects created with Java and distributed to my group as JAR files. Consequently, I do not have access to the actual Java source code. I only have the executable objects.

What is the best way to use C# to build applications that rely on the Java objects that the other group provides? I see lots of information on converting Java to C#, but I don't see anything on actually using Java within C#.

Can you help with this problem?

A> There are two things I can suggest:

1) J# ships with a tool called JBIMP.EXE which can be used to convert Java .class or .jar files to MSIL. Assuming that the JDK class library functionality used by the Java files you have is implemented in the J# class libraries, this should work great. Roughly speaking, J# provides JDK functionality for most business logic functionality. If that’s what the Java class files are implementing, you should have a pretty good migration percentage. Else, you may need to pass the /USESTUBREFS argument when calling JBIMP and re-implement some of the functionality.
2) You can look at a tool like JNBridge (www.jnbridge.com) which can provide intra-process interoperability between a Java Virtual Machine and the CLR. I highly recommend JNBridge – I’m not 100% sure of the constraints around this type of solution, but check out their Web site.