T
Test User
Guest
On Mon, 16 Jul 2007 19:59:53 -0400
"Mike Hall - MVP" <mikehall@mvps.org> wrote:
> Converting many programs to 64bit would show no benefit, so why do
> it. How much memory does MS Word or MapPoint realistically need.
> Games are realistic already. Most computer users will never require
> the kind of grunt that 64bit offers. Presently, I can't think of one
> mainstream program that seriously requires the 64bit touch, and until
> that program appears and can show visible benefits, 64bit will remain
> much as it is now..
>
Running linear algebra computations with maple on FreeBSD with
amd64-bits runs twice as fast as on the same hardware as i386,686, etc.
You don't need laborious benchmarks to see it. As for windows users,
some my find amd64 EVP beneficial.
AMD’s Enhanced Virus Protection acts as a preventative measure causing
the virus to be localized, short-lived, and non-contagious, eventually
being flushed from system memory.
Continued below:
http://www.amd.com/us-en/Weblets/0,,7832_11104_11105,00.html
You may also want to look at some benchmarks.
http://www.gen-x-pc.com/rev_amd64_3400.htm
http://www.thejemreport.com/mambo/content/view/74/
The real flexibility comes when the processor loads the 64-bit version of Windows; in that mode, called Long Mode, the computer can run both 32-bit and 64-bit Windows applications at full hardware speed. The backward compatibility with 32-bit applications is provided by the AMD64 processor on the hardware side; the operating system handles 32-bit calls by using a special technology called WoW64, for Windows-on-Windows 64, that translates 32-bit pointers and arguments into 64 bits and back again.
(A 32-bit application can find out whether it's running under WoW64 by calling the IsWow64Process function. Learn more about that function here.)
From a business and usability perspective, that means that users can keep all their existing 32-bit Windows apps, while being able to take advantage of the higher performance of any native 64-bit apps that they may own—and that's definitely the best way for users (and businesses) to begin the migration to the 64-bit world. And it eliminates much of the business risk for developers, like you, to begin the migration as well, because you don't have to convince your customers to walk away from their software investments.
Why Port to 64-Bit Windows?
There are several good reasons to port to 64-bit Windows. Several billion good reasons, in fact, including large memory!
The memory limitation for an application on a 32-bit legacy Windows platform is two gigabytes, which must be shared by all the 32-bit processes that are running. The limit can be raised to 3GB for some applications, but that's the absolute maximum address space. On 64-bit Windows, that limitation is blown out of the water—you're talking about a huge virtual address space, and hardware support for terabytes of physical memory.
That's not all. When running with a 64-bit operating system, 64-bit applications have access to 64-bit pointers, and many new 64-bit general-purpose registers and 128-bit floating-point registers. That gives your application much greater efficiency in performing complex operations within the processor, using registers to store all the variables.
The upshot: Fast performance, even when you're not taking advantage of that larger address space. Math-intensive operations, such as codecs, simulation, 3D, gaming, compression, and cryptography really fly using those extra registers and instructions. In most cases, unless you're an assembly programmer you won't have to worry about the details, because your AMD64 architecture optimizing compiler will help your app take advantage of those extra on-chip resources.
Some Code Really Must Be Ported
If you're running 64-bit Windows on an AMD64 processor, you can generally decide which applications should be ported to 64 bits, and which can be left on 32-bit for the foreseeable future. While your 3D graphics apps would benefit from 64-bit performance, for example, an email client might be just fine on 32-bit. And of course, you can perform interprocess communication and remote procedure calls between 32-bit and 64-bit apps running on the same machine using operating-system calls or other middleware.
However, due to the architecture of the AMD64 technology, and of Windows-on-Windows 64, there are some pieces of code that simply must be ported to 64 bits, because Windows does not allow "thunking" (that is, argument translation) at key areas that affect the operating system itself. For example, device drivers must match the operating system's bitness: If you're running a 64-bit OS, you need 64-bit drivers.
Also, although you can run both 64-bit and 32-bit applications simultaneously on 64-bit Windows, each application must be pure—it can't mix 32-bit and 64-bit code. So, if an application that you're porting uses external DLLs, components or libraries, you must obtain 64-bit versions of that code prior to completing your port.
Plus, in most cases, you can use a single source tree for both 32-bit and 64-bit versions of your applications. Use different makefiles, with the correct libraries (see "Some Code Really Must Be Ported") and compiler switches to compile binaries for both 32-bit and 64-bit platforms.
Integer Data, Pointers, and Arithmetic
There's some excellent advice about the porting process on the DevX AMD DevSource, so there's no reason to duplicate that advice. However, there are some pointers that I'd like to share regarding porting C/C++ code to 64 bits.
First, bear in mind that programming for 64-bit Windows is basically
the same as programming for 32-bit Windows. You'll use the same APIs
and programming conventions. However, you will encounter a few new data
types. For example, int and long remain 32 bits, but pointers become 64
bits. That means that you'll have to be careful about finding, and
fixing, any implicit assignments between ints and pointers in the code.
To put it another way: do not cast pointers to int, long, ULONG or DWORD
http://developer.amd.com/articlex.jsp?id=167
"Mike Hall - MVP" <mikehall@mvps.org> wrote:
> Converting many programs to 64bit would show no benefit, so why do
> it. How much memory does MS Word or MapPoint realistically need.
> Games are realistic already. Most computer users will never require
> the kind of grunt that 64bit offers. Presently, I can't think of one
> mainstream program that seriously requires the 64bit touch, and until
> that program appears and can show visible benefits, 64bit will remain
> much as it is now..
>
Running linear algebra computations with maple on FreeBSD with
amd64-bits runs twice as fast as on the same hardware as i386,686, etc.
You don't need laborious benchmarks to see it. As for windows users,
some my find amd64 EVP beneficial.
AMD’s Enhanced Virus Protection acts as a preventative measure causing
the virus to be localized, short-lived, and non-contagious, eventually
being flushed from system memory.
Continued below:
http://www.amd.com/us-en/Weblets/0,,7832_11104_11105,00.html
You may also want to look at some benchmarks.
http://www.gen-x-pc.com/rev_amd64_3400.htm
http://www.thejemreport.com/mambo/content/view/74/
The real flexibility comes when the processor loads the 64-bit version of Windows; in that mode, called Long Mode, the computer can run both 32-bit and 64-bit Windows applications at full hardware speed. The backward compatibility with 32-bit applications is provided by the AMD64 processor on the hardware side; the operating system handles 32-bit calls by using a special technology called WoW64, for Windows-on-Windows 64, that translates 32-bit pointers and arguments into 64 bits and back again.
(A 32-bit application can find out whether it's running under WoW64 by calling the IsWow64Process function. Learn more about that function here.)
From a business and usability perspective, that means that users can keep all their existing 32-bit Windows apps, while being able to take advantage of the higher performance of any native 64-bit apps that they may own—and that's definitely the best way for users (and businesses) to begin the migration to the 64-bit world. And it eliminates much of the business risk for developers, like you, to begin the migration as well, because you don't have to convince your customers to walk away from their software investments.
Why Port to 64-Bit Windows?
There are several good reasons to port to 64-bit Windows. Several billion good reasons, in fact, including large memory!
The memory limitation for an application on a 32-bit legacy Windows platform is two gigabytes, which must be shared by all the 32-bit processes that are running. The limit can be raised to 3GB for some applications, but that's the absolute maximum address space. On 64-bit Windows, that limitation is blown out of the water—you're talking about a huge virtual address space, and hardware support for terabytes of physical memory.
That's not all. When running with a 64-bit operating system, 64-bit applications have access to 64-bit pointers, and many new 64-bit general-purpose registers and 128-bit floating-point registers. That gives your application much greater efficiency in performing complex operations within the processor, using registers to store all the variables.
The upshot: Fast performance, even when you're not taking advantage of that larger address space. Math-intensive operations, such as codecs, simulation, 3D, gaming, compression, and cryptography really fly using those extra registers and instructions. In most cases, unless you're an assembly programmer you won't have to worry about the details, because your AMD64 architecture optimizing compiler will help your app take advantage of those extra on-chip resources.
Some Code Really Must Be Ported
If you're running 64-bit Windows on an AMD64 processor, you can generally decide which applications should be ported to 64 bits, and which can be left on 32-bit for the foreseeable future. While your 3D graphics apps would benefit from 64-bit performance, for example, an email client might be just fine on 32-bit. And of course, you can perform interprocess communication and remote procedure calls between 32-bit and 64-bit apps running on the same machine using operating-system calls or other middleware.
However, due to the architecture of the AMD64 technology, and of Windows-on-Windows 64, there are some pieces of code that simply must be ported to 64 bits, because Windows does not allow "thunking" (that is, argument translation) at key areas that affect the operating system itself. For example, device drivers must match the operating system's bitness: If you're running a 64-bit OS, you need 64-bit drivers.
Also, although you can run both 64-bit and 32-bit applications simultaneously on 64-bit Windows, each application must be pure—it can't mix 32-bit and 64-bit code. So, if an application that you're porting uses external DLLs, components or libraries, you must obtain 64-bit versions of that code prior to completing your port.
Plus, in most cases, you can use a single source tree for both 32-bit and 64-bit versions of your applications. Use different makefiles, with the correct libraries (see "Some Code Really Must Be Ported") and compiler switches to compile binaries for both 32-bit and 64-bit platforms.
Integer Data, Pointers, and Arithmetic
There's some excellent advice about the porting process on the DevX AMD DevSource, so there's no reason to duplicate that advice. However, there are some pointers that I'd like to share regarding porting C/C++ code to 64 bits.
First, bear in mind that programming for 64-bit Windows is basically
the same as programming for 32-bit Windows. You'll use the same APIs
and programming conventions. However, you will encounter a few new data
types. For example, int and long remain 32 bits, but pointers become 64
bits. That means that you'll have to be careful about finding, and
fixing, any implicit assignments between ints and pointers in the code.
To put it another way: do not cast pointers to int, long, ULONG or DWORD
http://developer.amd.com/articlex.jsp?id=167
F267147-3FE7-4C9B-A9A1-CCF158F3FA5C@microsoft.com...