Slashdot Mirror
Introduction to 64-bit Computing and x86-64
James writes "Ars Technica has an article up explaining 64-bit computing from the x86 angle, specifically from the angle of AMD's Hammer. The article explains the details in that usual Ars style, and I found it very useful for thinking about what kinds of applications I may want to put to the test on one of these when we get a box in the office. Even non-x86 freaks may appreciate this, since it breaks down some of the basic advantages of 64-bit computing, and just who can expect to see gains in the near future."
While IA-64 isn't as bad as many here like to paint it, I'm looking forward to x86-64, if for no other reason than the continued pressure and competition for Intel.
We've all heard the rumors that Intel has a 'secret' project to produce a P4 that executes x86-64. I have a feeling that they might have to unveil it, if only for marketing reasons. Wouldn't it be ironic, Intel adopting AMD's extensions to the x86 instruction set!
> "...thinking about what kinds of applications I may want to put to the test on one of these when we get a box in the office.
I bet it rips mp3s like a motherscratcher. Oh, you said "office"...
We really need your help
http://www.gofundme.com/help-sherry
I've read up on AMD's and Intel's 64 bit computing and its improvements over 32 bit. But the improvements over 32 bit just aren't worth the extra cost and administration time that home and small business users can afford. Lets wait until most large businesses that can afford the extra cost and hassle adopt 64bit before we home users do. Just wait and look for real advantages over 32 bit before we all jump on the 64 bit bandwagon.
After reading the topic article (of which I saw on HardOCP yesterday), I was left with one question. Can you mix 32 bit and 64 bit code inside of ONE process? I know the OS can support 32 bit and 64 bit processes under Long mode, but can you mix code in a single process? It would be nice to know if you could build an application, query the CPUID feature flags, and then produce optimized code paths for both 32 bit and 64 bit. This would be nice because you can just supply one set of binaries to your customers instead of two seperate binaries. Anyone have any experience with the Opteron who can answer this?
The main perk of popularization of 64 bits is, if we think of the future, that more source code will be written with 64 bit capability in mind. Long ints will be used where they seem to be needed, etc. Open source movement is probably the most obvious benefactor, considering how harnessing that extra mile is/will be a trivial matter of recompiling. If we get a fast, cheap, non-x86 64 bit system in the future, all the better. But 64 bit capability should definitely be available on the desktops of the masses also, whether they needed 10 gig databases or not! More power for AMD!
I'm looking forward to industrial strength, rock solid Opteron servers to finally put to rest all the speculation how Linux on x86 machines is not up to all the tasks of Solaris/HP-SUX systems...
Save your wrists today - switch to Dvorak
But what will be really interesting is when operating systems will be specifically designed for this. With 64bit, a lot of the cruft in 32bit operating systems can finally go away. For example, memory mapped I/O finally becomes useful again, shared libraries don't clash as easily, etc.
a small point, but the author is wrong about underflow. from the review:
you get a situation called either overflow (i.e. the result was greater than the highest positive integer) or underflow (i.e. the result was less than the largest negative integer)
underflow is when you're trying to represent a fractional number smaller than the smallest floating point number available. ie: you went too close to zero.
. . . but I'll be buying them if and only if they don't include TCPA/Palladium/Trusted PC Platform/Name of lockdown scheme of the week.
Furthermore, Intel supposedly has a fairly simple hack that they could implement to allow their 32-bit systems to address up to 512GB of memory. Still, the cleanest and most future-proof way to address the 4GB ceiling is a larger pointer
They forget to mention that even if you can have more than 4gb on xeon machine you cannot address any single block of more than 4gb. Forget about putting your oracle db into memory.
love is just extroverted narcissism
Do you know what you're talking about? By math speak most addresses are just integers, but in computers a (void *) can be cast to a unsigned long without any loss of data, but thats not the point. x86-64 can only access 40bits of physical/virtual address space, even though internal datapaths can handle 64bit. He says that the biggest improvement will be large math and double the registers. As for x86, it's always been a hack. Im not a 16bit x86 buff, but it used switchable banks of memory. At no point could you address more than 64k in a segment. In the pentium, Intel added PSE (page size extensions) with allow 36bits total memory, but only a 32bit address space. Thats why you can configure a x86 linux kernel to handle 64gigs of High Memory. This is useless for any kind of IO address space, and still only 2^32 can be seen by any process. In the Pentium Pro they added PAE (physical address extention) which again lead to 36-bit addressing, but if your EIP register is only 32 bits long, how do you represent code in 0xfffffffff? Extended addressing on the x86 has always been a hack. Finally with x86-64 programs will be able to see more than 4gigs (minus what the OS steals. Win2kPro takes 2gigs, but Win2kServer and Advanced Server can take 1). Even alphas only have a 43bit phy/vir address space. When the time comes when it's cheap to have a terabyte of ram, Im sure they will increase the address space. This time it's not a hack though
If you'd actually READ the article (and understood it) you'd see the author was differentiating between the adressable range and the number of bits that could be stored in an address. Obviously the old 8 bit CPUs used to combine registers (eg, the Z80 had the IX and IY if I remember correctly - probably not as it was so long ago!) - if they didn't they'd have 256 bytes of RAM! The old segmented address space of the x86 was just bizarre, due to the way the segment registers were used. The segment register was 16 bit, even though you only needed the top 4 bits, so you could access the same address space in thousands of ways, but were confined to a "window" of 64K in any segment ;-)
Code, Hardware, stuff like that.
"Why not do it?" is usually a bad question, but in this particular case, I think it's a good one. If there is no performance penalty when running in Legacy Mode, and if the Hammer is going to be cheap (read: reasonably priced compared to the P4), why NOT buy it?
It doesn't hurt, and it prepares you for the future, a future that will come, now or later. This way there'll at least be a chicken... then we can just wait for the eggs to appear. It's foolish to think that any eggs will appear before the chickens do. Afterall, the only place you can get a chicken from before there are eggs, is from AMD's chicken replication facility.
Businesses, as they develop, tend to end up supporting more and more legacy products and services, and relying on structures that have got stretched and stretched but actually changed as little as possible. Governments are held back by the weight of their Civil Services.
Back in the 70s and 80s, we had a completely new architecture every week (felt like..) and there was some real competition. But now the Intel x86 architecture is like some vast bloated Communist bureaucracy, with people in the back office still using quill pens and running mysterious private empires (Actually, we have 128 registers but we are only going to let you refer to 8, comrade. ) And all this stuff doubtless adds to development cost, power consumption, and die size.
What will make it collapse? A new clean 64 bit processor with wonderful porting tools? The combined skills of China, Taiwan and Korea? A completely new, simpler software design paradigm?
Or perhaps it doesn't matter and silicon is just so cheap that we can easily afford Soviet-bureaucracy-on-a-chip. But I doubt it. Ships eventually went from highly developed sail to steam and Diesel; trains went from steam to Diesel and electric; and phones are fast going from fixed to mobile. For the sake of my still finding this business interesting in five years time, I really hope there is a real paradigm shift around the corner.
Panurge has posted for the last time. Thanks for the positive moderations.
That's the question I have.
The article says x86-64 will make possible servers that will be 4x cheaper than the current Sparc/Alpha/SGI crop. That still translates into the $5-10k range, at least at first.
On top of that you'll need more memory (programs will be larger and will *require* more HD space and RAM).
Altogether I don't think even x86-64 is for the mass market. In a few years maybe, if it's a success.
that I don't need a 64-bit proc for at least 10 more years. Then again, they always used to tell me that it was the Ghz that counted, and now look at their new chip for mobile pcs. Very similar to what AMD has been doing for quite some time.
on second thought, I will get a 64-bit proc
YOU SUCK BALLS!
I remember when I got my first 386 based computer, it was a 386SX (40 MHz - by AMD); which used a 16-bit data bus on the "outside" and 32-bit internally. Do any of you think there will be a x86-64SX, that will work on today's 32-bit motherboards, while giving some of the advantages of 64-bit computing?
Accentuate the positive, don't waste your mod points on the negative.
To summarize, Microsoft might run into a chicken-and-egg problem on 64-Bits: Nobody runs Windows on 64-Bits because it's not faster -> Nobody makes Win64 software -> Nobody runs Windows on 64-Bits.
Add into that the fact that Microsoft is traditionally very incompetent and slow when it comes to adopting new architectures and you get the idea.
I think that Microsoft will lose the majority of their server marketshare and a large chunk of their desktop marketshare during that transition. Simple market inertia will prevent Microsoft to be thrown out of the desktop market, but because of the 64-Bit transition, the Linux desktop market might finally gain critical mass and endanger the Windows domination in the long term.
I feel old when you mention the Z80.
16 bit adressing was mostly done with the HL register, which was a kombination of two 8-bit registers (H and L).
I'm not an engineer.
What I got from this article (well written, BTW) is that 64-bit processors provide more processing power--a concept different from speed. For instance, a Porsche can fly down the highway, but its engine has insufficent power to tow a 5th wheel RV. A Mack truck isn't speedy, but has a strong engine that can tow the heaviest loads up the same speed--more work is performed.
That would be why Apple's PowerPCs are still in the running, despite their clock slowness. They are falling behind fast as, after a point, speed does matter, in combination with improved processor power in the latest 32-bit Pentiums, and certainly the Xeon. Vector processing, such as Altivec, helps keep Apple competitive with their current chips--just barely. Many in the PC community await AMD's offering while IBM works on blending its POWER chip technology into a 64-bit PowerPC, with Altivec.
Imagine making the Porsche's engine more powerful but maintaining its speed advantage so it can haul ass as well as tow. Add nitro for extra ooompf (vector processing) and you have a dream machine. That's why it seems that 64-bit apps and processors seem to be such a holy grail.
That's my take on it. Clarification is always appreciated.
Vos teneo officium eram periculosus ut vos recipero is.
"Should Apple move from 32-bit PPC to 64-bit PPC, Mac users should not expect the same kinds of performance gains that x86 software sees from the jump 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."
Well yea, they already have more then 0 general purpose registers, and a flat memory space, like every other chip besides x86 has had for the last 20 years now. The embedded chips I've used on projects that cost $7 a piece even have more registers then x86 does.
64bit is about the memory, and using that memory, plain and simple. x86 just happens to be using this as a chance to catch up with the cutting edge concepts of the 1980s.
As for x86 needs to die once and for all, it's hacked, hacked again, and hacked yet again. x86 was and is a 16bit system. And now AMD wants to hack it yet again. Can anyone doubt that 80% of the silicon is for supporting legacy apps at this point? Are people that damn lazy they can't type 'make' on a new system? It's not like anyone uses "int" anymore and assumes it's N bits long.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
It's more beautiful to use the hexadecimal. Too bad bowling numbers will be ugly when we all use hexadecimal.
I'm still reading the article, but too bad the vector registers are still only 128 bits.
Doubling the vector registers would nearly double performance for applications designed to make use of SIMD instructions (MMX, SSE, 3DNow!, etc.) New instructions would be needed to support the new wider VRs, but that hasn't stopped AMD or Intel in the past as far as adding SIMD capabilities and it shouldn't stop.
retrorocket.o not found, launch anyway?
but I'll be buying them if and only if they don't include TCPA/Palladium/Trusted PC Platform/Name of lockdown scheme of the week.
/. a while ago clarified this point quite a bit.
I dunno, TCPA seems kinda cool & useful. It doesn't lock down anything, it is basically just a way to encrypt/decrypt data without having the keys on a local file system (i.e. keys are stored on a black-box hardware). Spreading popularity of TCPA might also render Palladium and other DRM methods worthless. TCPA != DRM. Some IBM articles reported on
With TCPA, *you* would hold all the keys (since you can access your own hardware, hopefully), and no centralized entity (*cough* ms *cough*) would have anything to say about it.
Save your wrists today - switch to Dvorak
Yes, but having 36 bit address space on a 32 bit processor means memory bank switching. Do you remember segmentation? With a 64 bit processor the memory model can be flat up to a 64 bit address space. For now, 40 bit physical address space is plenty, when this changes, it can be increased while staying on a flat memory model.
I'm a signature virus. Please copy me to your signature so I can replicate.
these have been target at the server market since inception. of course desktop use has no need for a 64bit machine. desktop use has a need for multi SMP machines that are quiet and small. one processor gets the job done, but two just smokes it all up.
programs have always been getting larger and larger requiring more and more memory. nothing will change that except for perhaps a complete stagnation of the hardware industry.
If you think of existing software as 386 binary code, then obviously it's not going to benefit from any improvements to the x86 architecture. Moving to Athlon 64 will not magically make Windows 95 run faster any more than a move to Itanium would. It'll give a performance improvement only if 'compatibility mode' is faster than existing 32-bit CPUs.
A large base of installed software is an argument for keeping compatibility with the x86 instruction set, but not an argument per se for moving to some new instruction set which is a bit like x86 but not quite.
Anyway, existing software will be 'old software' very soon and so it won't matter that much how fast it runs, any new CPU will be fast enough. (Do I care whether WordStar runs a hundred times faster than it did on a PC-AT or a thousand times faster?) Any app for which performance really matters will be recompiled for the new processor anyway.
-- Ed Avis ed@membled.com
HL was the 16-bit accumulator (yes, it was the H and L 8-bit registers paired). There were two index registers that were 16-bit only, IX and IY. There were some undocumented instructions where you could split them into high and low halves and use them like the other 8-bit registers. The other register pairs were AF (8-bit accumulator and flags register), BC (loop counter c.f. CX on 8086 and ECX on 80386) and DE. There was an alternate register set which could be swapped in with the EXX instruction.
Stick Men
But I read the remainder of the article.
The 64 bit registers won't be very useful to most of us for a long time. I'm an engineer and I don't think I've ever overflowed a 32 bit integer, ever.
Most of us won't need the address space of x86-64 for 2-3 more years at the very least.
But doubling the number of GPRs and more importantly, doubling the number of vector regs... WOW.
Doubling the number of vector registers will increase throughput significantly for apps that use the vector regs and are recoded to use the extra registers. The nice thing about this is that for those applications that have already been coded to use vector registers, the hard work has already been done. Making use of the extra registers will be easy compared to the initial task of vectorizing your code in the first place. It will be a VERY short time before applications (at least open-source ones) that have SSE/3DNow!/MMX support will take advantage of the extra registers. When I say VERY short, I'm estimating 2-3 weeks or less after x86-64's general availability before we start seeing the patches flying.
As someone who does a lot of video encoding - This new architecture is making me drool. I was thinking of upgrading my box, but I think I'm going to wait until x86-64 is released.
retrorocket.o not found, launch anyway?
What are you talking about? Name one extra item of "cost" or "administration" or "hassle" that comes from using a 64-bit machine versus a 32-bit one.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
A couple of months ago I bought used Digital AlphaServer 2000 5/250. I am running Tru64 5.1B(former Digital Unix) on it. I really like Tru64. It is very reliable, efficient, has great administration tools and excellent documentation.
The best thing however is that Tru64 and Alpha hardware are very well integrated. OS can detect and configure hardware automatically. It can also (together with the great SRM firmware) monitor various components in case of a (very rare) hardware failure.
One of the worst things in x86 world is BIOS. It's limitations practically force operating systems not to use its services. On the Alpha however OS can rely on SRM console. This is a very nice thing. Two examples (AlphaServer 2000 has these nice features):
1. SMP CPU failover: AS2000 tests cpus when it is doing its hardware diagnostics and if it finds a cpu that is broken it simply disables this cpu (provided that there is another cpu to use as the primary cpu).
2. Memory failover: AS2000 can detect bad pages in RAM and disable them.
Most x86 systems don't have these features, Alpha and Sun systems have. Linux is not the primary problem here, clumsy x86 hardware is. I have read somewhere that Linux can do something like memory failover (something similar at least), but my point is that the hardware (and BIOS) should do it, not the operating system. X86 would be so much better if BIOS was replaced with OpenFirmware or something similar.
How does Intel currently kludge around the 4Gb memory limit on 32bit processors? The article alludes to a feature in the Xeon line that does this, but a quick Google didn't turn anything up. I assume it's some virtual memory style hack, where the pointer indexes into a table rather than directly into memory.
Chris
The article mentions 2 clear benefits of x86-64.
First, we have more addressable memory, which could help performance by running entire cached databases.
Second, he says for applications that do math on very large numbers (that need larger than 32bit numbers) there would be a performance increase because 64-bit cpus could do it in one register, instead of ia32 having to split it up.
However, he states that regular apps that donot require larger than 32-bit ints will see no performance increase on x86-64. My question is this: Would it be possible to "double up" the calculations by cramming more data into a single instruction if one were only using 32bit ints?
The compiler would have to intelligently arrange this I guess.
I think it should be noted that slashdot only reports the news from submissions. The article existed before it made the front page of slashdot, and people read it before it was on the front page of slashdot. Additionally, there are many other articles on the new architecture and this is not the first. I mean its not like the guys at ARS are the first to hear about this stuff.
You can get a 64bit v100 server from Sun for under a $1000 dollars...
16 bit adressing was mostly done with the HL register
Yes, HL was the main address pointer in the Z80. (BC and DE being the other ones.)
IX and IY were index registers: you had special instructions to access memory at (IX + n). You couldn't use them as general purpose registers, while you could perform arithmetics on HL.
WWTTD?
Yeah, especially since size_t is generally an unsigned type, but you need signed types for a lot of things -- not the least of which are loops that don't run forever accidentally because a signed vs. unsigned compare promotes to unsigned. Also, some system calls want to return a size_t, but return -1 on error. Hence you get weird things like ssize_t, or lazy programmers who just use 'int' because it "just works for all my data".
As for coding quality -- yes, I admit I have a lot of implicit 32-bitness built into certain parts of my code. At least, I assume int/unsigned int are 32 bits. And I know I'm not alone.
--JoeProgram Intellivision!
I bet the makers of MatLab and Mathematica will be creaming over this processor. Science and Math department will probably adopt this platform every early on. Since math and science students will be the main users of these systems, they will also be more inclined to by adopt this platform for their own personal use, especial since its 32-bit backwards compatible and -hopefully- affordable. If amd and the computer vendors play their cards right, they could sell these systems as the ultimate multi-purpose computer.
I just want to malloc a terabyte. Even if I don't use it for a little while (4GB is a limitation to me now).
In an article posted here AMD announces its new naming scheme for the Opteron family of processors. With their new model number scheme, they continue to fight the association of frequency with performance. The model numbers are new, but not the fight.
To know is to have knowledge....to understand is to be enlightened.
Unfortunatlely, the majority of people who had heard of Alpha just said "Nice, but we don't need it yet". Altavista was built as a technology demonstrator for the advantage of 64-bit addressing for databases and people still said "So what". Digital never made it to the big time for chip production and without the economics associated with real mass production, their stuff stayed pricey.
People understand the 8088 architecture and its descendants, which essentially just perpetrated the earlier errors, and they feel comfortable. Anything else is a risk. MS made NT run on Alpha, but the applications didn't follow as nobody saw the market.
See my journal, I write things there
Does this chip support tcpa (and thus palladium) ? I think this is a kind of an important detail on the new cpu.
The only good reason to switch to 64-bit computing is *memory*. The 4GB limit is a real problem for modern CAD tools.
Where I work (a semiconductors company) we use Sparc64 systems exactly for that reason.
In fact, the CAD tools manufacturers admit that their 64bit versions are *slower* than their 32bit software. The only reason a 64bit version is available is because a lot of customers are hitting the 4GB limit.
The reasons for the performance loss? Well, 64bit software may address more memory but it also CONSUMES more memory.
More importantly the processor's cache can now hold only half the data (if the same program is just recomplied its working set of int's is doubled!).
So for a given processor that have both 32 and 64 bit modes (Sparc, Hammer, PowerPC) the 32 bit mode is preferrable if the application can live with it...
If you take a look at the highway into town at 8 o'clock in the morning, 90% of the cars hold just one person.
Also, 90% of the cars have four or five seats.
Why restrict yourself to two seats if four can be had at a marginal extra expense, if any ?
Maybe some day you want to take a few extra passengers, even though the need never arouse during the last couple of years of commuting.
This is why consumers will buy 64-bit CPU's as soon as they are affordable.
When the 68000 came out, it had 32 bit registers, but only 24 bits went out of the chip to physical memory. So, it could only address 1 MB RAM. Later models (like my 68020 Mac) can address 32 bits of physical RAM (4 GB). But it took several years before RAM prices came down so that I could afford even 32 MB RAM (my Mac II's maximum). That's only 25 bits.
The AMD chip will support 40 bits physical, and a few more bits of virtual. So, a process will be able to be larger than physical RAM. Still, 40 bits of RAM is a terrabyte. That's about $100,000 US of RAM at the moment, assuming you can get a motherboard to support it. AMD will be able to bump up the virtual and physical RAM supportable without changes to existing code - right up to 64 bits. That's what Motorola did. At the moment, supporting more physical bits would have non-zero cost, with zero benefit.
One thing that additional virtual memory could do for a large corporation is aid in LAN distributed computing. Basically, one could have a shared RAM dataset span hundreds or thousands of desktop workstations. All machines would have access to all of the data over the network. The OS would translate virtual address references to physical - including finding the machine that has that chunk in it's RAM. The OS for the machine that has that chunk of RAM would coordinate changes to that RAM. This could allow a corporation to utilize their desktop investment for many supercomputing projects - reducing their supercomputing needs, saving them money.
It also allows one to more easily build a modern supercomputer with the chipset.
The Commodore 128 used a funky bank switch system to allow access to 128 KB RAM. This is kinda/sorta how Intel wants to extend the x86. IMO, this cripples the arch. Intel seems to be doing it because they want the Itanium to take off. However, the Itanium appears to be an expensive dog. I'd rather have any of it's 64 bit competitors, at the moment. It appears to me that the Itanium will cripple Intel, without regard to the backing of big corporate customers.
-- Stephen.
Maybe I missed it somewhere in the article, but I was kind of disturbed by the diagram showing what's possible in what modes. What it looks like they are saying is that in "legacy" mode, you can only run 32-bit code, and you must run a 32-bit OS. And in "long" mode, you must run a 64-bit OS, and v86 mode is not supported at all.
If a new x86-64 OS that takes advantage of the 64-bit extensions can no longer run v86 code, then this is going to be a serious hamper on adoption! There are still tons of reasons to run 16-bit code, like the BIOS-init in XFree86, DOS emulators, and of course we all know about Windows (though that is changing mostly with the adoption of NT as a home platform). I mean over time things are going to support 32-bit/64-bit code more and more (in the bios and such) but I thought the compatability was the whole point here...
Is this going to require some sort of trick like IBM used on the 286 with OS/2?* Can someone in the know post about this?
* Back when the 286 was brand spanking new and IBM was developing OS/2, they of course wanted to use the new protected mode. Only problem was, Intel didn't build in a way to switch out of protected mode! So if they wanted to run an old fashioned 8086 task (or any 8086 code) they ended up doing something that was described by the developers as "turning off the engine at 60mph" -- they'd actually completely reset the CPU and put in some glue to make it jump back into the OS image instead of the BIOS. Which is how it exited 286 protected mode :)
Cryptic Allusion - New Mac and Dreamcast Games!
When I was an intern at Intel (summer 2000), I attended a small presentation at the end of the summer where they pitched 64-bit computing. One of the questions at the end was when it will be available on the desktop, and the answer, amazingly enough, was that it wouldn't be in the foreseeable future. And I'm just sitting there thinking "Bad move". Because they completely ruled out the geek factor. So I'm glad AMD is there to clean up after Intel's mistakes, and offer us a 64-bit desktop solution.
Gotta get me one of these!
These look very interesting.. The large address space and native bignum math are nice, but not a big deal for me.. I really like the flat address space and increased number of general purpose registers.
This is sort of odd, since those two things are completely abstracted to me when programming in user space.
I was educated on processor architecture and assembly language on the Motorola 68000 processor. So, I have always found the x86 kludgery distasteful. The x86-64 gets rid of two of the major points of the x86 crap, and it feels like a decent architecture.
Now, how about a big-endian x86-64? That would be perfect!
- 80386 processor released in: 1985
- First 32bit Microsoft Windows release: April 1993
Result: 8 years to a relatively consumer level OS that took advantage of said processor. The 80486 was already out, and the Pentium was due very shortly (Summer 1993).I'd have to say that Intel won't be letting Microsoft do THAT again. Granted, today memory is cheap. The days of $50/MB are long gone...
-Chris
Damn it, I can't think straight here... I think the major reason why Windows 3.1 and WfW was "good enough" had more to do with the cost of memory at the time than it did with the software being "good enough". Fact is, Microsoft couldn't take the fragile assembly that was Windows in 1993 and make a 32bit OS out of it. The 5 year project that was NT proved just how hard it was for them to go ahead and do this.
To lend a bit of credence to my argument that 16bit wasn't good enough, was their effort to make OS/2 1.0 a 32bit OS. If not for IBM wanting support for the 80286, we'd have had a consumer level 32bit OS sooner than we did (although it might have sucked worse than Windows can sometimes).
Speak for yourself, brother. I and many of my contemporaries prefer grey on black... but yes, the usage of neon colors on a black screen must be reserved only for those of us on LSD.
Anyhow, anyone else regretting the day bgcolor=white became the default instead of grey?
-Chris
Right, because probably 90% of the computations you are going to be doing are with 32bit integers (in my database work, that's all I've ever really used, although I *HAVE* needed 64bit pointers).
The only reason to go to a 64bit CPU right now is the extra address space. Continue to count your money and stock valuation in 32bit integers. (Hell, some of us could get by with 16bit integers for that). But to count everyone in the world needs >32bit integer.
So you are right. Moving to 64bit addition and subtraction is pointless (right now). Letting me store a 6GB AVI movie in RAM for effects processing, however, is not.
-Chris
That's a shitty oven you have, AC. Of course, maybe it's an Easybake.
Athlon, P4 and Ultrasparc processors all produce about the same amount of heat, in the 50W-100W range (do specifics matter when you've got a tower case with a couple fans?).
Hands in my pocket
What's the status of the Fritz Chip w.r.t. this 64 bit processor?
To those of us with Alphas, 64bit is old news. About tens years old. Those running OpenVMS know that those sneaky old OpenVMS engineers even devised a scheme such that 32bit applications run quite blissfully in the newer 64bit environment.
On the Apple II, someone created very large RAM cards that addressed several MB of RAM using bank switching. Back then the limitation was heat and power. The cards were originally advertised to have up to 16 MB, but the reallities mentioned above limited them to about 4 MB without serious modifications such as fans and upgraded power supplies.
Sign of the times : I paid $120 or so for an extra 16KB for my Apple II+. 64K of RAM 80K total memory (including 16K of ROM) ! woo hoo !
Dean G.
So, without seeing any benchmarks, or having (I'm guessing) an intimate knowledge of this all, you already know:
a) the actual cost
b) the actual benefits
c) that the preferences for all users are such that the combination of a and b are not financially feasible.
Stop and think about it. How often is 64-bit integer math needed? Sometimes it is, yes, but I think the general consensus is that it is fairly uncommon. Everything from Word to The Sims to Doom 3 is not reliant on 64-bit integers in any kind of fundamental way. And for those applications that do need 64-bit integers, you can do 64-bit math right now by doing the it in multiple steps (so it takes a few cycles instead of one). You'd have to be doing a tremendous amount of 64-bit math for the difference to be significant.
Is making a processor 64-bits free? Of course not. You essentially have double the sizes of (a) all registers, (b) all internal data paths, (c) the ALU.
I get the feeling that a lot of people are fantasizing about what 64-bit processors will give them, and they're not looking at it from any kind of realistic angle. No one wants to hear that 64-bit isn't an across the board magic bullet.
Because the machine code *has* to change in the process, you can take the opportunity to redesign your instruction set to make it possible to design faster chips that use it. In AMD's case, they've added some registers and presumably cleaned up the sillier bits of the x86 instruction set. Intel has taken a different tack - they basically decided to wipe the slate clean and start again. As it turns out, they haven't really been able to make their clean-sheet design work very well yet.
Going to 64-bit code has its costs, also. Code density (the amount of machine code needed to do a task) goes down, so your memory system doesn't work as well. If a crucial bit of your program that fitted in the instruction cache in 32-bit mode doesn't in 64-bit mode, the 64-bit code would run considerably more slowly.
Speed is not the real issue here. The ability to work with large RAM sizes is.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
My argument is that to the consumers, 64-bits *will* be free. AMD is making the chips, and if they want to move them into the main stream, they'll have to price them as such. So for most people, there will be between 0 and x% benefit (where x is a positive number), and the additional cost over a competing cpu will be close to 0.
So, my point isn't that a 64 bit machine will be needed frequently at all - I'm not concentrating on the "benefit" side. Instead, I'm saying that since AMD has stated it wants to compete on the general desktop with the P4 and successors with their 64-bit chips, they will have to be priced such that the "cost" side is negligible, if not 0.
neye
It doesn't lock down anything, it is basically just a way to encrypt/decrypt data without having the keys on a local file system [...] With TCPA, *you* would hold all the keys
Nope. Not only does it not do any kind of really meaningful hardware crypto acceleration (it only performs operations using the RSA system, and doesn't support _any_ symmetric algorithms), it also hides the keys from you. They're generated in the trusted platform module and stay there for all time. It also comes with an endorsement key built-in, which is what makes it really dangerous.
Make no mistake. TCPA is just as damaging as Palladium to your freedom, if not moreso now that large portions of the tech community have been convinced otherwise.
My argument is that to the consumers, 64-bits *will* be free. AMD is making the chips, and if they want to move them into the main stream, they'll have to price them as such. So for most people, there will be between 0 and x% benefit (where x is a positive number), and the additional cost over a competing cpu will be close to 0.
Eventually this may be true, if you ignore the increased power consumption that will undoubtedly go with it. Until then, there will be cost resulting from all the incremental improvements that will occur along the road to to 64-bits, just as the road to AGP 4x took years and years and countless motherboard revisions. Consumers who get machines in mid-transition will almost certainly end up with PCs with shorter lifecycles.
HyperTransport - Don't Athlons already have this? (i.e. it's nothing new)
Not on any chip or motherboard I've seen offered for sale. It was going to be introduced with the Hammer/Opteron chipset.
But the other architectural improvements are going to make x86-64 a must-have for people LONG before the 4GB barrier being shattered will matter to the majority of computer users. Those extra registers will mean an instant performance improvement for everyone as soon as apps are recompiled to take advantage of them. They'll boost throughput quite a bit for video encoding/playback, same for 3D gaming.
3D gaming is primarily limited by your graphics card. Has been for quite some time.
Multimedia already uses the SSE vector register set, and so won't get much of a performance boost.
Add to that the fact that register renaming has been making register count less of an issue for years, and the strength of this benefit looks smaller and smaller.
It'll still _help_, but don't expect a larger register set to give a _vast_ performance boost.
Sorry - I don't buy that. You're talking about an industry that has prospered over the past 20 years largely by creating the perception that there is a continual need to upgrade. They'd probably be quite cheerful as they sold 0.001% of their market a special, expensive, backwards-compatible chip for legacy systems.
Remember the Cyrix "486". A chip that doesn't support _everything_, is broken as far as the customer is concerned. Selling a "mostly" compatible chip would be a great way to torpedo their own sales.
The Alpha version of NT4 ran using a backwards compatibility mode, ie only 32bit address space was available. However the initial work on making NT 64bit clean was done on the Alpha, taking advantage of the fact DEC/Compaq was funding it at the time.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
And ofcourse the Alpha was introduced in april 1992, not supported by NT4 until 96 or so, and ran in a 32bit mode. And i`m pretty certain that 64bit MIPS processors predated the Alpha, and NT ran on those too.. but also in 32bit mode. So microsoft finally produced a 32bit os, but only AFTER 64bit chips were available...
Will we see 128bit chips before a 64bit windows?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
NT 3.1 supported Alpha on release day (or shortly thereafter). In May 1994 when I started working professionally, NT was supported on Intel, MIPS and Alpha.
I think this time around, Intel isn't going to let Microsoft make that same mistake. And Microsoft CANNOT make that mistake if it wants to have a place in the Enterprise. In the late '80's and early 90's, Microsoft was happy owning the home computer, and small business. They had ZERO chance of competing in the Datacenter.
That's not true today. Today Windows 2000 server offers just as reliable a platform as Solaris or Tru64 does. 64bit support is necessary for Microsoft to continue to make money and keep their marketshare in the backoffice. 5 years from now, if they don't have a 64bit offering, SQL Server is going to look pretty pathetic next to postgres or SAP or Oracle on Solaris or Linux.
This time around, they have no choice.
-Chris
The V100 is a 1U rackable server designed for web usage with a 600MHz US-II CPU, this is not what I'm talking about. Yes it's 64-bit but you can't really use it as a compute or DB server for example.
Entry level general purpose Unix servers are in the $20,000 range. Divide by 4 and you still have an expensive machine that families or even small businesses are unlikely to buy in a hurry.
I guess my question should have been: will the 64-bit CPUs from AMD eventually replace the 32-bit ones? Will *really* cheap machines be made out of them, soon? Can we count on AMD to bring everybody to 64-bit computing soon?