Yesterday, one of the attendees from the
Virtualization events asked this question which I though would be worthwhile to share:
For a simple .NET application like this, would we need different applications when running on 64 vs. 32 bit hosts?
Before answering, please allow me to elaborate more on where the question is going. Virtual Server has a COM API that allows it to be managed by applications and scripts. Virtual Server R2 SP1 Beta 2 (phew) comes in two flavors: 32-bit and 64-bit. The owner of the question wondered if you could manipulate a 64-bit instance of Virtual Server using a 32-bit application (or vice-versa).
Ok, now that the question is (hopefully) a bit clearer, the answer to the question is
no, you do not need to have a different version for accessing Virtual Server from an application regardless of its bit-architecture. Why? Virtual Server's COM API is accessed by an out-of-process COM library, which means that everything is done by means of RPC. When two applications are communicating with each other by means of RPC, the 1st commandment of 64-bit is
not broken (thou shall not run 32-bit and 64-bit code within the same process space).
If the tasks that your application carries out are independent of each other, a way to optimize things is to create threads for various tasks. There are many ways to thread applications including Pthreads, windows threading, and recently OpenMP. OpenMP excels in the sense that it can make your application multi-threaded by just writing a few pragmas here and there.
Once you multi-thread your application, many things can go astray. For instance, different threads can access variables at different intervals in a loop, which can only lead to disastrous results in your calculations. You can break your head and lose some of your sanity by manually debugging what is going wrong with your application or you can use Intel's thread checker to find out what is going on. For instance, the following sceenshot shows you the output of all the problems (referred to as data races) when various threads were accessing variables and changing them on each loop:
Furthermore, your application's threads might starve waiting for a particular resource to be freed, which can only make the whole multi-threading effort futile. Tools like Intel's thread profiler can help you find this info. For example, after data collection, based on the following screenshot, you can pretty much tell that due to locks in the code, the threads are pretty much stalling the application:
Now that you know what these two tools are and what they do, what I wanted to show you was how to get around the fact that none of these tools can be installed on a Itanium box. That is, now that the Itanium is dual-core, how do you go about optimizing multi-threaded apps using these tools? The solution to this problem will be included in the second part of this post, stay tuned!
These days I have been testing all of our 64-bit labs on a
Montecito (Itanium) box that was lent to use by HP. The newest feature of
this new chip is the fact that it has two cores, which should make
multi-threaded applications perform a lot faster. I have not developed in
a while for the Itanium, and one of the first things that struck me was the
fact that there is no "Intel Compiler Installer" available for download.
As of version 9.1.028, the compiler installer includes compilers for x86, x64,
and IA64 - sweet.
While following my usual install procedure (click next until the installer
finishes) I noticed that my IA64 compiler was completely broken - even when
compiling a Hello World. The error I got was the following:
icl: internal error: Assertion failed (shared/driver/drvutils.c, line 535)
After reading some forums which did not hint me at all what the problem was, I
decided to re-install but this time around reading the installer
screens. It happens that one of the requirements for this compiler
to work is that it needs the PSDK from Microsoft installed, something that I
had completely forgotten to do. Once I installed the PSDK, the IA64
compiler was a happy camper and everything worked OK. Hopefully, some
desperate soul will be able to find this info if they ever face that dreaded
message.
Fact: You cannot install Visual Studio on an Itanium box - this is a "by design" issue and the installer will not budge regardless of what you try.
So if you are building binaries from Visual C++, how do you manage to make them run given that most of the libraries they need will not be found on the Itanium box?
One workaround is to statically link your binaries - which oftentimes lead to bloated sizes and defies the whole purpose of using dynamically linked libraries.
Another one is to install the Visual C++ Runtime libraries for Itanium and x64:
Install these on your 64-bit server and C++ binaries will run in all of their glory. With Remote Debugging and these utilities installed, you won't even need a RDC to the 64-bit box to run your code. Happy coding!
|
|
|
We recently received an interesting mail detailing the problems faced
when using MAPI to send mail via Office Outlook Express. Here are the
symptoms (try and see if you can figure it out by the end of the post): 1.
When using MAPI calls in a 32-bit application when Outlook Express is
the default e-mail handler, the application creates a blank message
(success) 2. When using MAPI calls in a 64-bit application when
Outlook Express is the default e-mail handler, the application creates
a blank message (success) 3. When using MAPI calls in a 32-bit
application when Office Outlook is the default e-mail handler, the
application creates a blank message (success) 4. When using MAPI calls in a 64-bit application when Outlook Express is the default e-mail handler, the application does not create
a blank message (failure). When the program ran and tried to create an
e-mail, the Outlook Express connection wizard showed up. After
comparing registry entries for hours trying to find why Office Outlook
was not being recognized as the default e-mail client and why Outlook
Express was, it then hit me. There is a 64-bit version of Outlook
Express on every 64-bit Windows install, that is why scenarios 1 &
2 above were working! There is some MAPI calls via DLLs, and since
there is a 64-bit version of Outlook Express, everything works fine
when it is the default e-mail client. The story with Office
Outlook is different. Since it is only 32-bit, when it is registered as
the default e-mail client, only the 32-bit section of the registry is
affected. That is why when the 64-bit MAPI program tries to send mail,
it only sees Outlook Express. This makes sense as the MAPI
functionality to work with Office Outlook is a 32-bit DLL, which would
not work when called from a 64-bit binary. As far as what can be
done to overcome this problem, you ask? I have not tested this, but if
you could build yourself an out-of-process 32-bit COM LocalServer that
was responsible for invoking the MAPI functionality of sending mails,
you could (in theory) invoke it from a 64-bit application and be done
with your bit-dependencies problem. This link
is a great place to start. I will be busy at an event here in Redmond,
but if I have some free time I will try to come up with the solution
and post it here, |
After reading Jose's blog
entry, I immediately had some questions about virtualization on the new
dual-core Itanium architecture. First and foremost, which software vendor
out there has a Virtualization solution that supports the Itanium? As far
as I know, the roadmap for Virtual Server 2005 R2 SP1 does not include support
for the Itanium. Longhorn's roadmap does not include any foreseen support
for the hypervisor on the Itanium either, so no luck in there as well.
Secondly, if some company indeed supported VT on the Itanium and allowed you to
say, run Windows XP 32-bit on a virtual machine, would that be faster
than running the a 32-bit application directly on Windows Server for the
Itanium? Also, how would the WoW64’s performance (which IMHO is the
Itanium's Achilles’ heel) be affected by the fact that there is VT support?
These are many, many questions for which I have no answer
for and hopefully will be addressed soon enough.
Starting today (like in 30 minutes ;) ), we will start the first
webcast in a series of three. These revolve around most of the
things we have discussed in the labs plus some new ones such as issues
with 64-bit installers, setting up VS for 64-bit deployment, and
multi-threading your application using OpenMP standards.
You can find the whole list
here. Tomorrow, Thursday 29th, I will be presenting a
webcast that
has many, many demos on how to preserve dependencies in 64-bit.
Feel free to stop by and let me know your comments once the session is
over.
If you really have no idea on what to expect when moving to 64-bit, then these webcasts are definitely worth listening to.