Re: When do you see Vista 64 being more main stream?
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,,..._11105,00.html
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
Re: When do you see Vista 64 being more main stream?
On Mon, 16 Jul 2007 21:30:12 -0400
"Mike Hall - MVP" <mikehall@mvps.org> wrote:
> Well, that is the theory..
> So how is all of this going to benefit MS Works, Nero, Stellarium,
> Zuma Deluxe, online Bingo, Yahoo chat, Limewire, address book,
> Calculator, Winzip, Blogger for Word..
You should see a speed increase in those programs you mentioned.
> Most of us are not running algebra computations, designing the wiring
> loom for the Boeing 797, computing wind tunnel results for the
> Ferrari 2008, putting together the next edition of the New York
> Times, monitoring the life support systems of the Shuttle..
This may be true, I'm just saying that you do have some benefits to
running AMD64. Many windows users are also gamers, so you will see the
benefits there also.
> There is little enough incentive to move to the next OS..
>
>
> "Test User" <Test@User.com> wrote in message
> news:I5Umi.84$ej2.21@newsfe02.lga...
> 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,,..._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
>
>
>
>
>
>
>
>
>
>
>
Seems like a small percentage of people use 64 for the 4gig ram
benefits. Wondering when you see Vista 64 being more main stream than
say 5% or so of users using it?
Re: When do you see Vista 64 being more main stream?
Your guess is as good as anyone's.
I would guess at least 2 years.
It will not happen until a larger % of hardware and software
manufacturers make products that use and benefit from 64 bit.
"gizbug" <gizbug.2tu7o9@no-mx.forums.net> wrote in message
news:gizbug.2tu7o9@no-mx.forums.net...
>
> Seems like a small percentage of people use 64 for the 4gig ram
> benefits. Wondering when you see Vista 64 being more main stream
> than
> say 5% or so of users using it?
>
> Next year? Never?
>
>
> --
> gizbug
Re: When do you see Vista 64 being more main stream?
Hello!
"gizbug" <gizbug.2tu7o9@no-mx.forums.net> wrote in message news:gizbug.2tu7o9@no-mx.forums.net...
>
> Seems like a small percentage of people use 64 for the 4gig ram
> benefits. Wondering when you see Vista 64 being more main stream than
> say 5% or so of users using it?
>
> Next year? Never?
>
This all wouldn't be a huge deal if there were a viable 64-bit operating system for the OEMs to ship their computers with, but there
isn't. I don't blame HP and Dell for not wanting to do any more of Microsoft's tech support. By botching the 64-bit implementation
instead of making the transition graceful (like Mac OS X does), they effectively stall out the market at 2GB.
..
.
.
Vista should've shipped 64-bit only and it should've shipped with a polished 64-bit implementation. This would've been the right
play for Microsoft as an industry leader, allowing XP to continue running on 32-bit systems, because this would've forced a
transition to 64-bit hardware and thus avoided this mess entirely.
SOLUTION: For those of you wanting to make the transition to 4GB or more of RAM, you may find XP Professional x64 Edition to your
liking. A free 120-day trial is available on Microsoft's site, and I've found the software compatibility to be exceptional, and the
system itself to be rock stable and an excellent performer. Driver support is still hit and miss, however; while finding 64-bit
drivers for my desktop was no problem, they were virtually impossible to find for my laptop. Still, those wishing to avoid Vista
while still enjoying the benefits of 4+ GB of RAM will likely be well served by XP x64.
As games and applications continue to come out that push the boundaries of computer hardware and run afoul of the 2GB barrier, these
problems will only pick up in pace. For many power users this experience will be a common occurrence, and for most it will be a
frustrating experience.
We're at the front end of a messy transition, one that may not end for several years. Today, 32bit games will hit the 2GB barrier,
and tomorrow games with support for large addressing will hit the 3GB/4GB barrier. Not until 64bit versions of games are ubiquitous
will we be completely through this transition, and that will still be a few years away.
Re: When do you see Vista 64 being more main stream?
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..
"gizbug" <gizbug.2tu7o9@no-mx.forums.net> wrote in message
news:gizbug.2tu7o9@no-mx.forums.net...
>
> Seems like a small percentage of people use 64 for the 4gig ram
> benefits. Wondering when you see Vista 64 being more main stream than
> say 5% or so of users using it?
>
> Next year? Never?
>
>
> --
> gizbug
Re: When do you see Vista 64 being more main stream?
"gizbug" <gizbug.2tu7o9@no-mx.forums.net> wrote in message
news:gizbug.2tu7o9@no-mx.forums.net...
> Seems like a small percentage of people use 64 for the 4gig ram
> benefits. Wondering when you see Vista 64 being more main stream than
> say 5% or so of users using it?
It's going to have to happen soon, at least for gamers and the like because
we are fast running out of memory. A lot of games are already using more
than 2GB (and crashing in a lot of cases because they're not compiled with
large_address_aware flagged).
I think within 2 or 3 years any high-end systems sold will be 64-bit. When
it becomes mainstream is a harder question to answer, I think budget systems
will continued to be sold with 32-bit for quite a while.
I'd like to think Microsoft would make the next major client version of
Windows 64-bit only, but I can't see them doing that (although Windows
Server 2008 will be the last 32-bit server).
Re: When do you see Vista 64 being more main stream?
When the price of RAM comes down enough that even budget computers have more
than 3 GB. It's like anything else that's new. Until there's enough systems
that have a lot of RAM there's no incentive to develop 64 bit apps. Once
there's enough systems out there and a small developer starts to take some
market share by selling 64 bit apps the big developers will jump on it and
things will snowball. I think it's all dependent on RAM prices but that's
just a guess.
"gizbug" <gizbug.2tu7o9@no-mx.forums.net> wrote in message
news:gizbug.2tu7o9@no-mx.forums.net...
>
> Seems like a small percentage of people use 64 for the 4gig ram
> benefits. Wondering when you see Vista 64 being more main stream than
> say 5% or so of users using it?
>
> Next year? Never?
>
>
> --
> gizbug
Re: When do you see Vista 64 being more main stream?
Well, that is the theory..
So how is all of this going to benefit MS Works, Nero, Stellarium, Zuma
Deluxe, online Bingo, Yahoo chat, Limewire, address book, Calculator,
Winzip, Blogger for Word..
Most of us are not running algebra computations, designing the wiring loom
for the Boeing 797, computing wind tunnel results for the Ferrari 2008,
putting together the next edition of the New York Times, monitoring the life
support systems of the Shuttle..
There is little enough incentive to move to the next OS..
"Test User" <Test@User.com> wrote in message
news:I5Umi.84$ej2.21@newsfe02.lga...
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,,..._11105,00.html
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
Re: When do you see Vista 64 being more main stream?
Motherboards supporting more than 4gb and the respective processors are
going to have to fall in price too, and still I will not manage more than 40
wpm in MS Word or WLM..
"Kerry Brown" <kerry@kdbNOSPAMsys-tems.c*a*m> wrote in message
news:615FA0D1-9786-4815-9596-B54DE7319588@microsoft.com...
> When the price of RAM comes down enough that even budget computers have
> more than 3 GB. It's like anything else that's new. Until there's enough
> systems that have a lot of RAM there's no incentive to develop 64 bit
> apps. Once there's enough systems out there and a small developer starts
> to take some market share by selling 64 bit apps the big developers will
> jump on it and things will snowball. I think it's all dependent on RAM
> prices but that's just a guess.
>
> --
> Kerry Brown
> Microsoft MVP - Shell/User
> http://www.vistahelp.ca
>
>
> "gizbug" <gizbug.2tu7o9@no-mx.forums.net> wrote in message
> news:gizbug.2tu7o9@no-mx.forums.net...
>>
>> Seems like a small percentage of people use 64 for the 4gig ram
>> benefits. Wondering when you see Vista 64 being more main stream than
>> say 5% or so of users using it?
>>
>> Next year? Never?
>>
>>
>> --
>> gizbug
>
Re: When do you see Vista 64 being more main stream? 
Linear Mode
