bendsley

I was asked the other day about this, so I thought I would put up a blurb about it on here incase anyone wanted to know. Please note that this article is not going to go into a great deal of depth.

For several years now, there have been rumors that 64-bit computing would soon become mainstream. We may have finally reached that point, but there are some problems. The market is filled with competing 64-bit standards, each requiring their own special version of Windows. I will explain what you need to know about the various 64-bit systems that are available today. As I do, I will talk about the limitations imposed by each.

Since about 2001, 64-bit computing has been available in at least some capacity. However, up to this point, 64-bit computing has been traditionally used by big data centers with huge budgets, and specialized 64-bit applications. All the while though, there have been rumors that 64-bit computing would soon be entering the main stream. Almost four years have passed, and it seems that we are finally at a turning point in which 64-bit computing may finally be upon us. Before you run out and buy a 64-bit system though, there are some important issues that you need to be aware of. In this article, I will attempt to cut through all of the speculation and marketing hype and tell you what you really need to know before you make the move to 64-bit computing.

What is 64-bit computing?

Before I get started, I wanted to take a moment and explain what 64-bit computing is and why it is so significant. As you probably know, computers process instructions in binary format. Each bit is capable of processing one binary instruction (zero or one) per clock cycle. Most of the PCs that are currently on the market have 32-bit processors, meaning that they can process 32 binary instructions per clock cycle.

Since 64-bit systems can process twice as many instructions per second as a comparable 32-bit system, 64-bit systems are definitely faster than their 32-bit counterparts. Perhaps the most significant difference between a 32-bit and a 64-bit system is the amount of memory that they support.

The fact that 32-bit systems only have 32-bits of data to work with means that they can only address up to 4 GB of RAM. A 64-bit system on the other hand could theoretically address up to 16 exabytes of RAM (That’s over 16,000,000 GB of RAM). In reality though, there are few, if any, 64-bit systems that support 16 exabytes of RAM. Building a machine that supports that much memory would be extraordinarily expensive. To counter this cost, many manufacturers impose RAM address space limits that fall somewhere between the 4 GB limit of 32-bit machines and the theoretical 16 exabytes that a 64-bit system should be capable of addressing. Most existing 64-bit systems limit physical RAM to somewhere between 8 GB and 256 TB.

The Intel VS. AMD Battle

Now that I have talked a little bit about the significance of 64-bit computing, I want to talk about the 64-bit solutions that are currently available. Currently, Intel, AMD, and Apple all offer 64-bit systems. However, the philosophies behind those systems couldn’t be more different.

I don’t really want to spend much time talking about Apple since this is a more Windows related blurb. It is worth mentioning though that Apple offers a Power Mac G5 with two 64-bit processors, running at 2.5 GHz. This liquid cooled machine is designed to be a workstation class computer.

Intel on the other hand has had a 64-bit system available for a long time now. Intel’s 64-bit processor is called the Itanium. Itanium machines are intended for use as servers. At the time that this article was written, Intel denies having any consumer level 64-bit systems planned for release any sooner than about 2006. The eventual release will roughly coincide with Microsoft’s Longhorn release.

The one major drawback to Itanium servers (aside from the price) is that they will only run 64-bit code. That means that companies who want a 64-bit Itanium server will be required to run 64-bit applications and 64-bit device drivers, both of which are currently difficult to come by. Itanium servers can use an emulator to run 32-bit applications, but 32-bit applications tend to run much more slowly in an emulator than they would run natively because of the additional overhead involved in translating the 32-bit code into a 64-bit format.

AMD’s 64-bit strategy is a lot different than Intel's. Currently, most of the machines that AMD is shipping have 64-bit processors. AMD offers 64-bit processors for server and for workstation class machines at prices that are competitive with Pentium 4 and Itanium machines. The interesting thing about most of AMD’s 64-bit processors is that they can natively run both 32-bit and 64-bit code. This means that today, you could install a regular, 32-bit version of Windows and then later on switch to a 64-bit version without having to upgrade your machine.

Where Does Windows Fit Into All of This?

So far I have talked about the AMD’s and Intel’s 64-bit solutions, but you might be wondering where Windows fits into the equation. After all, you won’t get any benefit from a 64-bit system if you aren’t running a 64-bit operating system.

The Microsoft Web site contains beta versions of the latest 64-bit versions of Windows Server 2003 and Windows XP. You can access the 64-bit downloads for Windows Server 2003 at http://www.microsoft.com/windowsserv...t/default.mspx You can download the 64-bit beta version of Windows XP Professional from http://www.microsoft.com/windowsxp/64bit/default.mspx

Before you start downloading these beta 64-bit editions of Windows though, there are a few things that you need to know. For starters, the 64-bit version of Windows XP will not run on Itanium processors. That’s because the Itanium processors and the 64-bit AMD processors are so different that they each require their own unique version of Windows. Microsoft does however offer both an AMD and an Intel 64-bit version of their Windows Server 2003 software.

The other thing that you need to be aware of is that, at least for now, the 64-bit version of Windows XP is lacking a lot of the features found in the 32-bit version. Among the missing features are: DVD playback, the ability to record to a CD, the Kodak imaging accessory, Windows Media Player, NetMeeting, IEEE 1394 audio, and fax capabilities. The 64-bit version of Windows XP is also missing almost all protocols except for TCP/IP, System Restore, the Windows Messenger Service, Remote Assistance, the File and Settings Transfer Wizard, and too many other features to list. It is possible that the server software may also be lacking similar features although I was unable to locate any information regarding missing features on the Internet.

Should I Buy a 64-Bit Computer?

Now that you know all about the way that the various manufacturers implement 64-bit processors, the real question is, should you buy one? The answer is that it really depends on who you ask. Many experts believe that 64-bit processing power is overkill for desktop machines. I tend to disagree though. Right this minute, there might not be a lot of 64-bit applications available for the average user, but I believe that in the not too distant future, 64-bit systems will be indispensable. Think about it… A few short years ago, only computer geeks would even think about running Windows NT Workstation on a home machine (yes, I was one of those geeks). Conventional wisdom at the time was that Windows 95 / 98 was for home users and Windows NT belonged at the office. Today though, even the most generic machines ship with Windows XP, which is based on the Windows NT kernel. My point is that while 64-bit processors in the home might seem ridiculous today, I don’t think it will be very long before they are common place. Gamers and those who heavily use CAD, desktop publishing, scientific, or graphic arts software will almost certainly benefit from 64-bit technology.

But what about today though? Today, you can walk into any computer store and buy a 64-bit desktop machine (or a laptop) with an AMD processor for under $1,500. Although you would have a 64-bit system though, you would have to run it in 32-bit mode unless you installed a 64-bit version of Windows. There are several problems with installing the 64-bit version of Windows XP though. First, the operating system is still in beta testing. Second, 64-bit hardware drivers are tough to come by, and the machine won’t work correctly if you use 32-bit drivers with a 64-bit operating system. Third, there are very few 64-bit applications available for Windows machines at the current time.

In my opinion, there is no reason to run out and buy a 64-bit system today. If you are in need of a new computer though and you know that it will be a few years before you can upgrade again, then it might behoove you to go ahead and buy a 64-bit system. That way, you can run the standard 32-bit version of Windows XP professional today, but as drivers and applications become more readily available, you can upgrade to the 64-bit version of windows without having to invest in new hardware.

If you are one of those people who has to be on the cutting edge, you can run a 64-bit operating system today. Just keep in mind that you probably won’t be able to use the 64-bit version of Windows XP as your primary operating system because of the lack of available applications. Of course Windows isn’t the only operating system on the block. You could always go with a 64-bit version of Linux.

-Brien M. Posey

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

Hanabal

good read,

but if its at all possible, can you tell me other advantages of 64bit computing. cause not many people are close to 4gigs of ram today.

also wouldnt the speed increase be reduced because of the increased traffic from the higher bit count. ie double the data needs to be loaded into memory and then passed to the processor, this will surely have a negative impact

__________________
I am Hanabal, Phear my elephants

Cynthetiq

seems like the difference between RISC and CISC... a bunch of marketing hype that doesn't change the end user experience all that much.

thanks for the details...

__________________
I don't care if you are black, white, purple, green, Chinese, Japanese, Korean, hippie, cop, bum, admin, user, English, Irish, French, Catholic, Protestant, Jewish, Buddhist, Muslim, indian, cowboy, tall, short, fat, skinny, emo, punk, mod, rocker, straight, gay, lesbian, jock, nerd, geek, Democrat, Republican, Libertarian, Independent, driver, pedestrian, or bicyclist, either you're an asshole or you're not.

the_marq

So does this mean that during the transition period from 32-bit to 64-bit there will likely be two versions of most software available?

IE: In 2006 will we see a version of Halflife 3 for 32 and 64-bit PC's?

...or am I missing the point?

__________________
The Truth:

Johnny Cash could have kicked Bruce Lee's ass if he wanted to.

#3 in a series

bendsley

I have actually seen a version of FarCry for both the 32-bit and 64-bit platforms.

Though, the 64-bit will actually play on the 32-bit systems.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

vox_rox

The 64-bit circus, as mentioned in the article, is certainly NOT ready for prime time, and there is exactly zero reasons to go there unless you are a beta tester or a computer science student/professor/professional.

If you just wait, 64-bit computing will iht its stride, but 32-bit computing is fast, stable, and easy to access right now.

The one thing not mentioned in the article (he DID say it was a Windows article after all) is that there are several distributions of Linux/Unix etc. that will compile and run on these 64-bit machines and will run in 64-bit mode. As well, there are 64-bit apps for them as well, though most apps are still running in emulation, albeit faster.

so, there is light at the end of the tunnel, but unless you have a good tan and don't mind spending A LOT of time in that tunnel, ignore 64-bit computing until it gets a bit more mature.

Just my $0.02 worth.

Peace,

Pierre

__________________
---
There is no such thing as strong coffee - only weak people.
---

sailor

One note: while running a 64-bit OS is nothing more than a geek penis-size contest (one in which I happily compete ), the Athlon 64 processors are amazing. Totally aside from their ability to run 64-bit and 32-bit code natively, they run games faster than any other processor out there--and generally cheaper than their Intel counterparts. Great chips. My current processor is one, and my next one will be too.

__________________
"Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws."
--Plato

Mephisto2

SIGH

So I wasted my time buying an AMD 64 last week?

Oh well.


Mr Mephisto

Mephisto2

I just noticed Sailor's post as I hit submit. I feel a little bit better now.


Mr Mephisto

bltzkriegmcanon

Most excellent read sir! I'm actually considering investing in a 64-bit CPU, but have yet to make the leap. I think the applications will come with time, but I'm truly undecided as to what platform to go to. Intel, who *might* launch a multi-core, 64-bit processor in 2006, or AMD with their ever-awesome single-core, 64-bit processor which is available NOW. And, like others have said before, at a significantly lower cost than Intel's high-end 32-bit CPUs. Ah, the decisions of an Intel fanboy.

__________________
What do you say to one last showdown?
- Ocelot, Metal Gear Solid 3

The password is "Who are the Patriots?" and "La-Li-Lu-Le-Lo." "La-Li-Lu-Le-Lo." Gotcha.
- The Colonel and Snake, Metal Gear Solid 3

Rawb

Just a quick correction:

This is wrong. An instruction on a CISC arch like x86 has a variable number of bits per instruction, MMX instructions are far more than 32-bits, and the smallest instructions I believe are above 8-bits. Modern CPU's don't get anywhere close to the 1 instruction per clock cycle, typically more like .3 instructions per clock cycle (due to cache fetches, reads from ram, etc). Also, 64-bit instructions are typically much larger than their 32-bit counterparts, due to it being a 64-bit operation. So some programs (which reference a lot of memory addresses by pointers) will even run slower in 64-bit mode than in 32-bit mode, due to the extra memory accesses eating cache area.

In my opinion the primary reason to move to the AMD64 platform today is twofold:
1. The Athlon64 is a well built processor, the on-chip memory controller, coupled with the much shorter pipeline makes it an excellent performer.
2. 4 gigs of ram as a real bottleneck is coming closer and closer. Due to Virtual Memory (which is in all modern operating systems), a 32-bit system can only use 2-3 gigs of actual ram per process (so a big database on Win32 for example can't use any more than 2gigs of ram).

Also, on an aside, thanks to the open-source nature of linux and most of the software that runs on linux, you can run in pure 64-bit mode very easily. The only thing that I miss on a regular basis is the WMV codec for playing videos and the flash plugin. Other than those two things, everything is pure 64-bit for me.

Lasereth

Here's my summary: don't buy an Athlon 64 unless you're gonna play PC games.

-Lasereth

__________________
"A Darwinian attacks his theory, seeking to find flaws. An ID believer defends his theory, seeking to conceal flaws." -Roger Ebert

bendsley

aoeuhtns:
As I said at the beginning of the article, I didn't want to go too in depth.
----------------------------------------------------------------------
The "abbreviated" lifecycle of an instruction

The basic action of any microprocessor as it moves through the instruction stream can be broken down into a series of four simple steps, which each instruction in the code stream goes through in order to be executed:

1. Fetch the next instruction from the address stored in the program counter.
2. Store that instruction in the instruction register and decode it, and increment the address in the program counter.
3. Execute the instruction currently in the instruction register. If the instruction is not a branch instruction but an arithmetic instruction, send it to the proper ALU.

a. Read the contents of the input registers.
b. Add the contents of the input registers.

4. Write the results of that instruction from the ALU back into the destination register.

In a modern processor, the four steps above get repeated over and over again until the program is finished executing. These are, in fact, the four stages in a classic RISC pipeline. (I'll define the term "pipeline" shortly; for now, just think of a pipeline as a series of stages that each instruction in the code stream must pass through when the code stream is being executed.) Here are the four stages in their abbreviated form, the form in which you'll most often see them:

1. Fetch
2. Decode
3. Execute
4. Write (or "write-back")

Each of the above stages could be said to represent one phase in the "lifecycle" of an instruction. An instruction starts out in the fetch phase, moves to the decode phase, then to the execute phase, and finally to the write phase. Each phase takes a fixed, but by no means equal, amount of time. In the "example processor" I'm thinking of, all four phases take an equal amount of time; this is not usually the case in real-world processors. In any case, if a simple example processor takes exactly 1 nanosecond to complete each stage, then the that processor can finish one instruction every 4 nanoseconds.

Side note: If there is someone that wants a much better explanation of 64bit processors, I will be more than happy to divvy something up.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

SiNai

Please, I would like to hear it if you had the time and patience to explain it!

Also, on your (I'm assuming condensed) pipeline, where does memory load/store fit in? After execution, right?

__________________
I can't seem to remember now
What it was like- to live life, before you.. symbiont

bendsley

Simplistic operation of a processor is characterized by a fetch-decode-execute cycle. In the first phase of the cycle, the processor fetches an instruction from memory. The address of the instruction to fetch is stored in an internal register named the program counter, or PC. As the processor is waiting for the memory to respond with the instruction, it increments the PC. This means the fetch phase of the next cycle will fetch the instruction in the next sequential location in memory (unless the PC is modified by a later phase of the cycle).

In the decode phase the processor stores the information returned by the memory in another internal register, known as the instruction register, or IR. The IR now holds a single machine instruction, encoded as a binary number. The processor decodes the value in the IR in order to figure out which operations to perform in the next stage.

In the execution stage the processor actually carries out the instruction. This step often requires further memory operations; for example, the instruction may direct the processor to fetch two operands from memory, add them, and store the result in a third location (the addresses of the operands and the result are also encoded as part of the instruction). At the end of this phase the machine starts the cycle over again by entering the fetch phase for the next instruction.

Instructions can be classified as one of three major types: arithmetic/logic, data transfer, and control. Arithmetic and logic instructions apply primitive functions of one or two arguments, for example addition, multiplication, or logical AND. In some machines the arguments are fetched from main memory and the result is returned to main memory, but more often the operands are all in registers inside the CPU. Most machines have a set of general purpose registers that can be used for holding such operands. For example the HP-PA processor in Hewlett-Packard workstations has 32 such registers, each of which holds a single number.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

bendsley

64-bit Computing and x86-64

AMD's 64-bit alternative: x86-64

When AMD set out to alter the x86 ISA in order to bring it into the world of 64-bit computing, they took the opportunity to do more than just widen the GPRs. x86-64 makes a number of improvements to x86, and in this section we'll look at some of them.

Extended registers

I don't want to get into a historical discussion of the evolution of what eventually became the modern x86 ISA as Intel's hardware went from 4-bit to 8-bit to 16-bit to 32-bit. You can find such discussions elsewhere, if you're interested. I'll only point out that what we now consider to be the "x86 ISA" was first introduced in 1978 with the release of the 8086. The 8086 had four, 16-bit GPRs and four, 16-bit registers that were intended to hold memory addresses but could be used as GPRs. (The four GPRs, though, could not be used to store memory addresses in 16-bit addressing mode.)

With the release of the 386, Intel extended the x86 ISA to support 32 bits by doubling the size of original eight, 16-bit registers. In order to access the extended portion of these registers, assembly language programmers used a different set of register mnemonics.

With x86-64, AMD has done pretty much the same thing that Intel did to enable the 16-bit to 32-bit transition--they've doubled the sizes of the 8 GPRs and assigning new mnemonics to the extended registers. However, extending the existing eight GPRs isn't the only change AMD made to the x86 register model.

More registers

One of the oldest and longest-running gripes about x86 is that the programming model has only eight GPRs, eight FPRs, and eight SIMD registers. All newer RISC ISAs support many more architectural registers; the PowerPC ISA, for instance, specifies thirty-two of each type of register. Increasing the number of registers allows the processor to cache more data where the execution units can access it immediately; this translates in to a reduced number of LOADs and STOREs, which means less memory subsystem traffic, less waiting for data to load, etc. More registers also give the compiler or programmer more flexibility to schedule instructions so that dependencies are reduced and pipeline bubbles are kept to a minimum.

Modern x86 CPUs get around some of these limitations by means of a trick called register renaming. I won't describe this technique in detail, here, but it involves putting extra, "hidden," internal registers onto the die and then dynamically mapping the programmer-visible registers to these internal, machine-visible registers. The P4, for instance, has 128 of these microarchitectural rename registers, which allow it to store more data closer to the ALU and reduce dependencies. The take-home point is this: of P4's 128 GPRs, only the traditional 8 are visible to the programmer or compiler; the other 120 are visible only to the P4's internal register rename logic, so it's up to the P4's hardware to try and make the best use of them at runtime.

In spite of the benefits of register renaming, it would still be nicer to have more registers directly accessible to the programmer via the x86 ISA. This would allow a compiler or an assembly language programmer more flexibility and control to statically optimize the code. It would also allow a decrease in the number of memory access instructions (LOADs and STOREs). So in extending x86 to 64 bits, AMD has also taken the opportunity to double the number of GPRs and SIMD registers available via the x86-64 ISA.

When running in 64-bit mode, x86-64 programmers will have access to eight additional GPRs, for a total of 16 GPRs. Furthermore, there are eight new SIMD registers, added for use in SSE/SSE2 code. So the number of GPRs and SIMD registers available to x86-64 programmers will go from eight each to sixteen each.

Switching modes

Full binary compatibility with existing x86 code, both 32-bit and older 16-bit flavors, is one of x86-64's greatest strengths. x86-64 accomplishes this using a nested series of modes. The first and least interesting mode is legacy mode. When in legacy mode, the processor functions exactly like a standard x86 CPU--it runs a 32-bit OS and 32-bit code exclusively, and none of x86-64's added capabilities are turned on.

In short, the Hammer in legacy mode will look like just another Athlon.

It's in the 64-bit long mode that things start to get interesting. To run application software in long mode you need a 64-bit OS. Long mode provides two sub-modes--64-bit mode and compatibility mode--in which the OS can run either x86-64 or vanilla x86 code.

So, legacy x86 code (both 32-bit and 16-bit) runs under a 64-bit OS in compatibility mode, and x86-64 code runs under a 64-bit OS in 64-bit mode. Only code running in long mode's 64-bit sub-mode can take advantage of all the new features of x86-64. Legacy x86 code running in long mode's compatibility sub-mode, for example, cannot see the extended parts of the registers, cannot use the eight extra registers, and is limited to the first 4GB of memory.

These modes are set for each segment of code on a per-segment basis by means of two bits in the segment's code segment descriptor. The chip examines these two bits so that it knows whether to treat a particular chunk of code as 32-bit or 64-bit.

I've already discussed how only the integer and address operations are really affected by the shift to 64 bits, so it makes sense that only those instructions would be affected by the change. If all the addresses are now 64-bit, then there's no need to change anything about the address instructions apart from their default pointer size. If a LOAD in 32-bit legacy mode takes a 32-bit address pointer, then a LOAD in 64-bit mode takes a 64-bit address pointer.

Integer instructions, on the other hand, are a different matter. You don't always need to use 64-bit integers, and there's no need to take up cache space and memory bandwidth with 64-bit integers if your application needs only smaller 32- or 16-bit ones. So it's not in the programmer's best interest to have the default integer size be 64 bits. Hence the default data size for integer instructions is 32 bits, and if you want to use a larger or smaller integer then you must add an optional prefix to the instruction that overrides the default. This prefix, which AMD calls the REX prefix (presumably for "register extension"), is one byte in length. This means that 64-bit instructions are one byte longer, a fact that makes for slightly increased code sizes.

Increased code size is bad, because bigger code takes up more cache and more bandwidth. However, the effect of this prefix scheme on real-world code size will depend on the number of 64-bit integer instructions in a program's instruction mix. AMD estimates that the average increase in code size from x86 code to equivalent x86-64 code is less than 10%, mostly due to the prefixes.

It's essential to AMD's plans for x86-64 that there be no performance penalty for running in legacy or compatibility mode versus long mode. The two backwards compatibility modes don't give you the performance enhancing benefits of x86-64 (specifically, more registers), but they don't incur any added overhead, either. A legacy 32-bit program simply ignores x86-64's added features, so they don't affect it one way or the other. AMD intends for x86-64 to be a straightforward upgrade from x86, and this means best in class 32-bit performance along with 64-bit support.

Old Stuff

In addition to fattening up the x86 ISA by increasing the number and sizes of its registers, x86-64 also slims it down by kicking out some of the older and less frequently used features that have been kept thus far in the name of backward compatibility.

When AMD's engineers started looking for legacy x86 features to jettison, the first thing to go was the segmented memory model. Programs written to the x86-64 ISA will use a flat, 64-bit virtual address space. Furthermore, legacy x86 applications running in long mode's compatibility sub-mode must run in protected mode. Support for real mode and virtual-8086 mode are absent in long mode and available only in legacy mode. This isn't too much of a hassle, though, since, except for a few fairly old legacy applications, modern x86 apps use protected mode.

If you'll recall our previous discussion of the benefits of increased dynamic range, you might've noticed that, with the possible exception of security/encryption, none of the application types that currently make use of 64-bit addresses and/or integers are really consumer-level applications. Rather, they're all "back-end" in some respect. So there really is no market for 64-bit consumer apps, yet. The main reason that there is no 64-bit consumer market is quite obvious: for all practical purposes, the market for consumer application software is the x86 software market, and x86 is 32-bit. Applications that need 64 bits are built for hardware like MIPS, SPARC, Power4, Alpha, etc., and people who want to run 64-bit apps buy this specialized hardware to run them on.

You might say, then, that x86-64 faces a chicken-and-egg problem: there are no consumer-level 64-bit applications because there is no consumer-level 64-bit hardware, and there is no consumer-level 64-bit hardware because there are no consumer-level 64-bit applications. Depending on who you listen to, AMD or their detractors, either the former or latter reason takes precedence. AMD hopes that the former reason is primary, and that if they build an affordable, backward compatible 64-bit x86 processor then the applications will come. Others, however, insist that there just aren't any good practical or theoretical reasons at this point for 64 bits on the desktop, and that making the hardware available won't magically create those reasons.

In some sense, both sides are justified in their thinking. If and when AMD makes consumer-level 64-bit hardware available at an attractive price/performance point, coders may come up with new, as-yet-unconceived-of consumer applications that make use of the hardware's expanded capabilities. People have ways of finding innovative uses for better hardware; witness the completely unexpected rise of the consumer 3D graphics chipset industry, or the entire application spaces made possible by increases in DRAM and mass storage capacities. AMD is no doubt hoping that a similar thing will happen with x86-64.

The "if you built it they will come" plan isn't so far-fetched, since it's what anyone who puts out a high-performance CPU for the consumer market (read: both AMD and Intel) is already counting on. What to do with all the CPU horsepower is by now a serious marketing problem, and Intel pours millions a year into software research in order to stimulate the development of mass-market applications that require something like a P4 2.8GHz. So AMD has good reason, based on solid historical precedent, to expect that by expanding capabilities of the x86 ISA they'll be able to expand the ISA's reach to new market niches.

By some accounts, x86-64 is already making some inroads into a market segment that matters a great deal to anyone pushing a new PC technology: computer gamers. In a recent post to a Slashdot discussion of Intel's claims that consumers won't need 64 bits before the end of the decade, Epic Games's Unreal engine guru Tim Sweeny made the following comments, worth quoting in full:

I reproduced Tim Sweeney's Slashdot post because it points to the very real possibility that the amateur game modification community, which is a surprisingly large community that produces a huge amount of freely available content, will soon want 64-bit machines with which to create content for the next generation of games. I'm not suggesting that the mod community represents a large enough consumer market to make x86-64 a success, but I would certainly say that developments in the hard-core gaming enthusiast/early adopter community have a way of rippling out to affect the rest of the consumer market. Again, witness the rise of consumer 3D graphics, seeded by a single piece of software: GLQuake.

Even more relevant is the release of the new x86-64 port of the Counter-Strike server software. Counter-Strike (or CS, as it's commonly called) is far and away the most successful online shooter in recent memory, and the CS team claims a stunning 30% performance gain from porting it to x86-64 with no optimization. A significant portion of this gain probably comes from the benefits associated with x86-64's increased number of registers. The rest is from the Opteron's on-die DDR controller, large L2 cache and microarchitectural enhancements.

The success of the 3D graphics industry has shown that gamers can and will buy very expensive, dedicated hardware to enhance their gaming experience. If AMD can keep supplies up and prices down for x86-64 parts, then better-performing 64-bit versions of just a few popular games (or even one massively popular game) could go a long way toward driving x86-64's adoption in the marketplace.

A few final words about performance

Note that I attributed the CS performance increase to x86-64's larger number of registers, and not the increased register width. On applications that do not require the extended dynamic range afforded by larger integers (and this covers the vast majority of applications, including games), the only kind of performance increase that you can expect from a straight 64-bit port is whatever additional performance you get from having more memory available. As I said earlier, 64-bitness, by itself, doesn't really improve performance for anything but the rare 64-bit integer application. In the case of x86-64, it's the added registers and other changes that actually account for better performance on normal apps like games.

Should Apple move from 32-bit PPC to 64-bit PPC, Mac users should not expect the same kinds of ISA-related performance gains that x86 software sees when ported to x86-64. 64-bit PPC gives you larger integers and more memory, and that's about it. There are no extra registers, no cleaned up addressing scheme, etc., because the PPC ISA doesn't really need these kinds of revisions to bring it into the modern era.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

Rawb

bendsley, well done, quite the informative piece of work you have there. I am impressed.

For my debian pure64-bit install at least those extra registers have made all the difference in the world. It's really quite amazing the amount of speed that I picked up from going from a 32-bit install to a 64-bit install. But with the new Pentium 4's getting the amd64 extensions (or x86-64, whatever floats your boat), the only top-tier x86 platform that isn't going to have them is the Pentium M.

bendsley

thank ya aoeuhtns

I currently use a laptop as my desktop system at work. Bought the most expensive laptop Dell had a couple of months back (Dell Latitude D800). It has a Pentium M 2Ghz processor in it. I am quite amazed at how fast it is, considering too that it also has 2mb's of L2 cache on-die.

__________________
"You hear the one about the fella who died, went to the pearly gates? St. Peter let him in. Sees a guy in a suit making a closing argument. Says, "Who's that?" St. Peter says, "Oh, that's God. Thinks he's Denny Crane."

KnifeMissile

I'm sorry, but my understanding is totally different from this. I couldn't finish reading your post because I was stuck on this issue so I would like this cleared up, please.

"Each bit is capable of processing one binary instruction per clock cycle?" This makes no sense to me. Consequently, "...meaning they can process 32 binary instructions per clock cycle" makes no sense to me, either.

A bit is a contraction of the term binary digit. So, a number represented with 64 binary digits is referred to as a 64 bit number.

Back in the day, PCs used to use 16 bit processors, the 386 being the last of them. What this meant is that the registers on the processor were 16 bits wide. Because you manipulated registers with the processor, this meant that the largest numbers you can manipulate with a 16 bit processor were 16 bit numbers, which have a maximum value of 2^16 -1 = 165535. As you can see, this is not a large number and so, in some respects, limited what the processor can do. Of course programs for the 386 could manipulate numbers larger than this (it would have been alomost useless if it couldn't) but it couldn't do so with the native instruction set. It had to simulate operations of larger numbers using an equivalent combination of 16 bit operations, which was much slower. For performance reasons, this also meant that pointers were restricted to 16 bit integers, which restricted the amount of accessible RAM to a measly 64KB without resorting to hardware hackery (which, incidentally, they did! This is a whole other story on its own and quite a funny one...).

The 486 marked the first 32 bit processor the the PC. It could perform 32 bit operations, with a maximum integer size of 2^32 - 1 = 4294967296, a little over a billion. Not only was this a much more useful integer limit but it also allowed the processor to address 4GB of RAM. Quite a lot of RAM to be sure but, as you can see, this is not an impossible amount of RAM for a home computer to have. In fact, it will probably be only a few years before people will consider this to be typical. We're also, now, considering switching to 64 bit processors. Coincidence? I'll let you decide.

So, now we're pushing for 64 bit processors. Incidentally, there were plenty of processors with wider registers than Intel's. The N64 was called that because it had a 64 bit processor (Motorola MIPS 4300, if memeory serves me). Many Sun prcessors in the mid 90's had 128 bit processors. So, this is hardly incredible technology. It is simply a choice and we're making this choice now because we want more RAM.

I look forward to reading the rest of your article, bendsley, but I would greatly appreciate it if you could clear this up.
Thanks!

-Ever-

I didn't know G5's are liquid cooled...

__________________
Embracing the goddess energy within yourselves will bring all of you to a new understanding and valuing of life. A vision that inspires you to live and love on planet Earth. Like a priceless jewel buried in dark layers of soil and stone, Earth radiates her brilliant beauty into the caverns of space and time. Perhaps you are aware of those who watch over your home And experience of this place to visit and play with reality. You are becoming aware of yourself as a gamemaster...
--Acknowledge your weaknesses--

Yakk

And, modern CPUs are perfectly capable of running real mode in pure emulation. In fact, most programs run better in emulation, because you can control the virtual clock speed.

The windows default 2-GB addressable user memory problem is actually a problem. I too work at a company that runs into the 2-GB barrier.

We have 64 bit CPUs which we are writing software for.

This is on crack. And wrong!

To repeat what others have said:
The Athlong 64 bit chip rocks for many reasons other than it being 64 bits. The 64 bit ness of it is just icing on the cake.

This I hadn't heard. Cute -- Intel copying AMD's instruction set!

__________________
Last edited by JHVH : 10-29-4004 BC at 09:00 PM. Reason: Time for a rest.

bodypainter

The 2.5 ghz G5 dualie is liquid cooled.

fckm

Actually, the best reason to go to 64 bit is simple. AMD is EOLing the socketA processors, so in the future, the only chips you'll see from AMD are the 32bit low end Semprons, and the mid-high range 64bit Athlon64s. Starting in mid 2005, Intel will also be anouncing desktop 64bit cpu's. Like it or not, you're not going to get a choice in the matter. The world is moving to 64bit.

__________________
And if you say to me tomorrow, oh what fun it all would be.
Then what's to stop us, pretty baby. But What Is And What Should Never Be.

oblar

Very nice read, although I think I will be going 64-bit for one main reason. Price. 64-bit athlon chips are just as cheap as the (almost) equivalent 32-bit processers, but the 64-bits run even the 32-bit code faster.

in my personal opinion, after seeing first hand some of the 64-bit amd chips run go ahead and buy a 64-bit machine if you are in the market right now, but don't think you need to immediatley upgrade your "outdated" 32-bit processor.

I didn't know the Itanium and the A64 were so different that part was especially interesting.