Home
About
Apple
Career
Experiences
General
Graphics
Hardware
History
Humor
Interface
Networking
OS
Opinion
Politics
Programming
Quotes
Reviews
Security
Software
Sound
Thought
Web
Cheap International
Airfare Online
Wachovia online banking
Get Free Coupons Online
Finding the perfect
discount hot tub
Payday Loans
Stock Trading Online
Stuffed Animals
Smart Investing Online
|
|
64 bits
How much should you care?
By: David K. Every
|
Kind:
Created:
Size: |
Article
2002-10-14 08:20:01
19 KB |
|
|
 |
 he concept of "64 bit computers" is rearing its head again. The Itanic, er, Itanium is 64 bit, AMD is coming out with its own next generation x86 processor that will support both 32 and 64 bit, and IBM's GPUL (next generation PowerPC) or rumors of the G5 are also 64 bit. This all begs the questions, "how is this better for me?" The answer is surprisingly little.
People get caught up in hype; if 16 is good, then 32 must be twice as good. And if 32 is good, then 64 has to be great. The truths of engineering aren't that clear. Don't get me wrong, I think that 64 bits is going to help a few people a lot, and a lot of people a little bit. But the real advantages that will matter to me most, will have little to do with whether they are 32 or 64 bits; and a few problems are going to be created by this leap.
           
There are three ways to measure a processors "size";
- How many bits of data a processor works with
- How many bits a processor uses to address memory
- How many bits can move around at once
      
A processor works with certain data sizes at a time. Microcomputers started at 4 bits (with the Intel 4004). That turned out to be too little data to do anything of value -- even then, a character took 8 bits, and so with a 4 bit computer you were always having to do multiple 4 bit instructions to process a single 8 bit chunk (character) of data.
Quickly8 bits became the standard. 8 bits made sense since a single character of text (upper or lower case, and all numbers and symbols), took 7 or 8 bits to encode. So 8 bits was a good size that lasted for a few years.
While 8 bits was good for characters, it wasn't as good for number crunching. An 8 bit number (2^8) is only any whole number between 0 and 255. To do heavy math, you needed to work with more bits at once. The more the merrier. 16 bits could get you a value between 0 and 65535 (an integer)-- which is a lot more detail in a single pass --so 16 was better than 8 bits -- but if 16 bits was better for math, then 32 was better still. Lots of numbers in daily use are larger that 65,000 -- so 16 bits was also requiring double-passes to get things done. 32 bits was much better for integer math -- since it allowed a range of 0 - 4,000,000,000 (or +2B to -2B signed). That was good enough for about 99%+ of integer math. And it could even do some reasonable fixed or floating-point math as well; a concept where the computer sacrifices some of the resolution of the number, so that it can have a mantissa (multiplier), and basically allowing numbers much larger, smaller and with a decimal point.
The Motorola processors basically skipped from 8 bit (6800) to 32 bit (68000) processors (around 1980) because 16 bit was only marginally better than 8 bit, and you really wanted 32 bits for most work. Intel made a half-assed step from 8 bit (8080) to 16 bit around the same time as Motorola -- but sort of got lodged in 16 bit for a while with (8088, 8086, 80286), and it took them a while (6-8 years, or until like 1987 or so) to get with the program and catch on. Intel was ever the wallflower when it came to good technology and design.
Well 32 bits turned out to be good enough for most integer math for many years. I've been using 32 bit registers since 1979, basically there isn't a huge need for integers larger than that. And 32 bits meant you could move 4 characters around at once, and work with large integers. So there wasn't a huge pressing need.
Not all math is an integer (whole numbers between 0 and 4 Billion, or between -2 Billion and 2 Billion if you steal one bit to denote positive or negative integer) -- what if you want decimals or fractions (real numbers)? Well, you can cheat and encode some fractions or decimal values using 32 bits, but you lose resolution (total range). So they are only good for some things. AltiVec usually uses these lower resolution 32 bit floating point numbers.
While 32 bits was good enough for most things, for some scientific applications, or if you were working with the national debt down to the penny, then you have problems. To encode a real number with accuracy good enough for most science and math applications (and plenty of range) you need 64 bits. But again, 64 bits is usually for floating point, and rarely used for integers. In the early 1980's people used to add special "floating point processors" or FPU's (Floating Point Units) to help your main processor do this kind of math -- and make microcomputers behave like big mainframes and lab computers. By the early 90s, floating point units got added to the main processors (and are integral)-- and we've stayed there ever since. But there is a separation between kinds of data: 32 bits for integers (or short floats), and 64 bits for long floats. And until very recently, you used 8 bits for characters: but since you aren't usually doing math or anything on characters, you'd just move characters around using the Integer or Floating Point units.
In the late 1990's, there was a new game in town; it was short-throw vector processing, or single-instruction multiple-data (SIMD). This is known by the names of AltiVec on the PPC, or MMX and SSE (or 3Dnow) on x86 processors. The concept of vector processing goes back to the super computers, like the Cray-1, of the 1980's, and even before. The biggest change is that SIMD breaks a long data chunk (128-256 bits) into many smaller pieces (1, 4, 8, 16, 32 or 64 bit parts); or in other words, a single instruction can work on multiple data elements at once. So instead of the 128 bit AltiVec unit being just one big register, it can behave like 16 individual 8 bit computers, or as 8 individual 16 bit computers, or as 4 individual 32 bit computers, or even behave like many 1 bit computers, or a single 128 or 256 bit computer. It is very versatile. So it isn't just bigger, it is better, for some things.
  
When we used to ask how many bits of data a processor worked with, it was easy. There was one unit, and it always worked in that amount of bits. Now days there are 3 primary ALU's (arithmetic units), and each works on a different size. For large data chunks or arrays of low-resolution items, you use the vector unit (AltiVec). If you need to just have a simple counter or work with integers, then the Integer unit executes the instructions (32 bits). And when you need larger or more accurate 64 bit floating point numbers, then the Floating-point unit handles the instructions. So depending on what you are doing, will result in the size of data you are working with. In data size, the PPC is already 128 bits for at least some things.
A few things are changing. One is that after 40 years, we're finally moving away from 8 bits to represent a character of text. Instead we're using 16 bits (and Unicode). This allows for a character to represent not only any roman character, or a character in one language; but it allows for each character to be unique in any language in the world; and even beyond. Some were petitioning for Klingon and Elvish to add science fiction and fantasy character sets; for those of us who speak and need to type in elvish. This added width requirement will either make computer less efficient in speed, nominally, and a more inefficient in storage. But wider computers will help compensate. However, Unicode is a very minor motivation. The real reasons for moving are more tangible.
While 32 bit integers are good enough for 99% of computing math -- things are easier to do in your computer if your processors integers match at least the width (the total size) of their addresses. This is so the computer can do math easily on its own addresses, and see anywhere in it's memory at one flat space. Since computers are getting more memory, i.e. wider addresses, and going beyond 32 bits (or a mere 4 gigabytes), why not give them the full next power of two, or 64 bits of address space. This isn't a huge win for data speed. In fact, since addresses now take twice as much memory to remember, it is actually a minor loss for some things. But it is the biggest motivation for going to 64 bit addresses.
Now a computer has an address for each and every memory location. 8 bits of address, mean that your computer can address 256 addresses (locations) - usually these were each one byte long, but in theory, they could be as wide as the computer needed them to be. 256 addresses isn't much -- so even 8 bit computers would often work with 16 bits of address to enable them to work with 65,536 bytes (or address 64K of memory). You'd be surprised what we could do with computers back then, even with that little memory. Now my controller in my mouse is more powerful than the computers I started programming on.
Now days we have 32 bit addresses -- and a 32 bit address, can deal with 4 Billion addresses (4 Gigabytes of memory). 32 bit addresses have been standard for quite some time, and will be for a while. But we are starting to get to the point where 4 gigabytes of RAM isn't that much. For some large databases or large 3D or math problems, 4 Billion locations is very small. Now most of us aren't mapping the human genome on our home computers; so it isn't like we're all bumping our heads daily. But it is getting to the point where video and graphics work especially could use more space. So we want to make room for it now. And so designers are looking at jumping to 64 bits, or roughly 16 exobytes of memory to prepare for the future.
Now an exobyte is a quintillion memory locations: or 1,000,000,000,000,000,000, or enough memory to track every cell of every person on the face of the earth. So we shouldn't bump our heads on that limit any time soon. The naming goes, mega (million), giga (billion), tera (trillion), peta (quadrillion), exo (quintillion). While these are the popular terms, they are not technically correct terms. Peta means quadrillion -- but petabyte roughly means 2^50, instead of 10^16, which is really 1.1259 quadrillion. And Exobytes is worse, it means 2^60, instead of 10^19, or 1.15... quintillion. So actually, 16 exobytes is about 18.5 quintillion bytes of memory, but what's an extra 2.5 quintillion bytes of memory among friends?
Anyway, 64 bits of addressing is a heck of a lot of memory, and as I said, 32 bits is good enough for most users today (and for the next 4 or 5 years or so). So going from 32 to 64 bit addressing, isn't a huge win for the average user. For a few problems the extra address space helps; but not as much as you might think. The common hack (fix), is that the computer just have pages of 4 gigabyte chunks, and flips around to which very large page that it is looking at a time. And there are other techniques like segmenting, branch islands, relative addressing and so on, that can all work around addressing more memory than fits in one page at a time. So it is easy to address more than 4 gigabytes on a 32 bit computer; but just as you might find it annoying and slow to flip back and forth between two pages to compare something, or remember to use the 4000th location from this one, the computer and many programs aren't exactly thrilled with it; they prefer one big page. And given the choice, flatter is better.
Before you tell me how old Intel processors with 64K pages, and 640K limits sucked, remember that was because DOS and Windows didn't handle it well. Other compilers, languages, OS's and processors handled these paging issues much better. So the problems weren’t all fundamental, most were just with the particular implementations.
 
Now ironically, just because a computer (processor) works certain sized data (in registers), or has a certain size address space, does not mean that it move around that much data at one time. Computers have different areas that are different widths. There is the size of the internal registers, the size of the math it can do at once (ALU - Arithmetic Logical Unit), the size of the cache (width), and the size of the bus (channel / pipe from the cache to the memory).
Going from the processor to memory is the bus (or memory bus) may be different than going from the processor to the internal cache. We used to care about the processor to main memory the most (before cache) -- but now days, 95% of the time (or more) when the processor is accessing something, it is getting it from the cache. So the cache size is more important, right? Not as much as you might think, because main memory is up to 10 times slower. So there is a balancing act in design, and between all the sizes in your system. And if you make one part that is 10 or 100 times faster than the rest, it is just wasted potential, because it sits and waits for the other part to catch up all the time.
Interestingly, the PowerPC (called a 32 bit processor) has a 64 bit bus. If you go off-chip, it moves 64 bits at the same time. Even in integers, it has to move 64 bits to the processor (from memory), even if it only needs to see 32 bits of what it loads. So by bus width, it is a 64 bit processor. The 68000 was a 32 bit computer that worked with 32 bits internally, had a 32 bit ALU, and had 32 bit registers -- but it only had a 16 bit bus. While the Intel 8088 was an 8 bit computer that could pair registers (to pretend to be 16 bits) and had an 8 bit bus, and an 16 bit ALU. So the press and PC-advocates called both the 8088 and the 68000, 16 bit computers; even when the 68000 was often four times the computer that the 8088 was. Pro-Intel bias is nothing new.
Internally, processors are changing version to version. Some have 64, 128 or 256 bit wide internal paths, or sometimes they are wider to cache than they are to their memory bus. This is mainly because the cost of wider memory is significant. This is also a game with some of Intel's memory (like RDRAM), which is faster but not as wide; so it has to be faster just break even. There are lots of games with what constitutes processor width.
Another internal channel is for doing math: the ALU. The rest of the processor is basically for moving things around and doing simpler instructions (loops, branches, conditionals, etc.), but the ALU is where you crunch numbers. The G3 has a 32 bit ALU, while most floating-point instructions are 64 bits, so it takes two passes (twice as long). The G4 has a full 64 bit ALU, so it takes a single cycle -- and in fact, the G4 also has another 128 bit ALU to do vector instructions (and it can do so at the same time it is doing integer and floating point). The Pentiums have a 64 bit ALU (mostly), but for some things it is as slow (or slower) than the 32 bit ALU in the G3. Then most Pentiums didn't have a full 128 bit ALU, so were never as good for vectors. AMD has a better ALU than the Pentiums, and that is one of the reasons why their processors are faster at the same speed. So it can get pretty complex pretty fast, and it isn’t just about bits, but about how well the processor is designed.
So you can see that there are a lot of little areas where data is moving around -- and they are all different sizes for different reasons.
   
Basically, it isn't that hard to make complete predictions. But the basics are that most new “64 bit” processors, will have older “32 bit modes”. Applications and operating systems that use those modes won’t be able to take advantage of more than 4 Gigabytes of memory at once, but once again, this is not a huge deal for most Applications.
In the PowerPC camp, there is backwards support in the hardware. And there are a few ways to make the OS and software compatible. All in all, it is not a huge effort; but changes to the OS take time. There are also a few ways Apple can do it. The easiest way is to make the OS have old 32 pages for most apps, and a “new” 64 bit clean way to compile new apps, then just let programs evolve in time. Or there is the change the entire OS at once, and make sure everything (including all the OS’s API’s) can work in flat 64 bits; but that is generally harder and more time consuming. Apple could also be their “new” annoying self, and make one set of API’s 64 bit clean (like Cocoa), and not the other (Carbon), as a way to try to force people into the API that they want. But I don’t think that “migration at gunpoint” is looked on favorably by most customers and developers, nor do I think that it would be a good idea.
Since I don’t know which approach Apple is going to take, it is hard to guestimate how much time it will take. I think Apple knew that 64 bits was coming, or should have, when doing OS X, so it shouldn’t be a huge effort. But things were rushed, QA at new Apple wasn’t like the old Apple, and they might have been sloppy. So it might take longer. But in general, going to 64 bit is less effort (by far) than going from OS 9 to OS X.
In the Intel camp, Intel is trying to jump to 64 bit with the Itaniums, by changing the entire instruction set and design, and make it more like the PowerPC. (More modern in instruction set, and more RISC like, with some post-RISC design elements). And this requires whole new variants of the OS to work. So far, this strategy has been flopping. PC’s have always been about cheap and backwards compatible, not about good or well designed, or accepting big changes. Every effort to fix major design flaws, has flopped, and usually more conservative efforts have succeeded. Intel is relearning this the hard way.
AMD is taking a much better approach, with a 32/64 bit hybrid chip with backwards compatibility. And OS’s and Apps will probably take a more evolutionary approach as well. I suspect that AMD is going to win that game, right up until Intel copies AMD, and makes a few things incompatible, and the PC market follows Intel.
There is a murphy's law of communication (or should be) -- that no matter which way you mean something, others will assume you mean it a different way. And when talking about size, you could mean data size, path size (bus or internal), or address size. Generally, when we’re talking now days about chip size (how many bits), we mean is it a full 64 bit, non-paged, address and integer (data) support. Since I already have 64, 128 or 256 but support for other things, that’s about the only thing left that is that small. But remember, for most work, I don’t care about address space, I care about data size and speed; and we’re already there.
Will 64 bits matter? For most users, it will matter very little. Since moving 64 bits around (addresses) will slow things down (and increase the space they take), there could be a minor performance and memory efficiency loss; however I think other design improvements in the chips that offer 64 bit support, will more than make up for the bulkier addresses and data creep (wasted space). So we’ll get better performance, and they will be better chips, but almost none of that will be because they have 64 bit addresses and integer support.
There are definite areas where people will care about the larger address space. Large graphics, audio and publishing solutions, while not bumping their heads right now (very often), are starting to get close. Certainly large video, 3D and database solutions could use the full 64 bit support. So the big thing that 64 bit addressing does is buy us headroom for the future.
The only constant is change. I’m sure some day, we’ll be talking about that annoying 64 bit address space limit, and making the jump to a full 128 or 256 bit computers. But each transition has lasted us longer and longer, because there are fewer and fewer things that a computer can’t do with the speed and memory that they can address. So unless there’s some huge surprise, that takes a ton of memory (like home genome sequencers, etc.), then I expect that transition will be many years if not decades away. 
 Format for Printing  Mail
|
|
|
|
