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 article claims that since an address is just an integer, larger integers would mean more address space. And then it briefly mentions that the x86-64 has 40 bit addresses. I.e. not the entire 64 bit integer is used for the address. However, 32 bit x86 systems has 36 or 40 (not sure which one) bits adresses. The address space has nothing to do with the size of the data.
On the other hand, the 16 bit x86 processors could address 1MB, which is a 20 bit address space. 8 bit processors, like the one used in the old Commodore 64 could address 64KB, a 16 bit address space.
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
There are some interresting points in there... and judging from the post amount this early, many didn't ;)
:)
Yes I am off topic
.: Max Romantschuk
"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.
options.
.asp, or are you just glad to be here? robbIE, tell 'em about the payper. bettor yet, ask lairIE to tell 'em. how about 10 UNmoderated questions for robbIE/lairIE? you asked for it.
lookout bullow. the daze of the Godless phonIE payper liesense hostage ransom stock markup badtoll are nearing an end.
take heart dough, almost everything's gnu now.
is that smoke coming out of your
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.
Wonderful porting tools? Why bother with porting tools if you can just have the translation done at runtime? That's what Transmeta does with their Crusoe chips. The x86 instructions just become a shorthand to be translated into native VLIW instructions.
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
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
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....
Yes, another dupe. Only thing new is the fact that the Mods no longer add "yes, it's a dupe" on the front page anymore :(
Must-not-watch TV!
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 thought pentium2 and above putaz had 36bit addy extensions already.
the problem is rather to get some decent and reasonably priced chipsets that support more than just 2 or 3 gigz o mem.
serverworks and intels crap is high priced and for server market only if u wana have more than 3 or 4 gigs o ram.
jeez get real and dont tell me that u need some 64bit putaz just cos u have a 4 gig limit. most of the machines these days barely manage to use 2gigs of ram like i wrote above.
some manufacturers better manage to supply some nice chipsets first, to make use of the 36bit address space, and then later we might talk about 64bit.
You can get a 64bit v100 server from Sun for under a $1000 dollars...
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).
"Well, although I have never seen a review about that, never seen a Wintel64 system on sale and don't know what dirty hacks and workarounds are in the package, let's assume that's true."
w in dows/story/0,10801,69787,00.html
Look in even a Usenet binaries tracking site and they will likely list the 64 bit edition of Windows. Even the pirates have had betas since mid-late 2002. As for your clueless speculations of "dirty hacks" remember a little processor called Alpha? Windows NT was from NT4 on was using the Alpha as the native base for development. Let me also assert right now that MS has a very big leg up in the 64 bit space both in developers familiar and facilities available when compared to the open source community in general and the Linux camp in particular. Things like NUMA support don't just appear out of thin air yet is seems apparent that the 64 bit edition of Windows supports it out of the box. Some customers e.g. Canadian banks have been beta testing the 64 bit Windows since early 2001.
"Now look at my post again: All the points I made are still valid, the most important one being that Linux is being supported right from the start for the first time."
Oh come on that statement is really BS. You conveniently forgot about the introduction of the Athlon XP and MP chips. Both of these processors had new instructions and new architectures which Linux supported from day one.
"In case you forgot, Microsoft was YEARS late in finally adequately supporting 32-Bit (actually, Intel was already quite angry at MS that their chips were still used in 16-Bit mode almost exclusively for so long). Of course by that time, there was no alternative, so Microsoft got away with their incompetence, but now there is not only an alternative, it is also supported officially by AMD and Intel."
BS again. The market decided that the Win 3.11 and Win9.x operating systems were good enough. Windows NT was quite viable and fully 32 bit for a long time. The problem is people did not want to change their hardware and applications which is what a big change to a more demanding OS like NT would have required. You do remember Win32S calls in Windows 3.11 right? They were free additions to the stock Windows 3.11 system.
What kills me about your slanted views is that they seem to have forced you into a train of thought that has caused you to miss the real advantages Linux has over Windows with this new architecture shift.
1) Open source means you can recompile. Sure you will need rewrites to fully leverage the hardware and granted some things like drivers will need to be rewritten. (As an aside I'd love to see an Asound 10/100 PCI NIC driver or one that works with the ALN10x chipset under Linux as it will no longer be possible to use the old one without reverting to 32bit calls.) But overall Linux apps will get the advantage largely from the get go. Let's not forget though that most commercial companies will be responsive on the MS front as well there will be a greater lag time in adoption if historical trends continue.
2) Linux is free and somewhat popular. Sure Linux is not a powerhouse in sheer numbers but it has found many niches. This facilitates the solution to the chicken and the egg problem. Compelling apps and an OS that is free are available for this launch and the niches Linux occupies are good areas for 64 bit computing.
I am sure others can think of more.
http://www.computerworld.com/softwaretopics/os/
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
That "black-box hardware" is black even to the owner of the system--the writer of the key decides its export policy. So no, *you* wouldn't hold all the keys.
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.
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!
It comes down to this:
1. There are some applications that can make good use of having 64-bit integer registers (remember that FP registers are already 80-bit), but it tends to be a small, specialized set of applications in certain fields.
2. Doubling the size of integer registers is non-trivial in terms of transistor count, die space, and power consumption.
3. You can do 64-bit integer math on existing hardware at a good clip. It takes two instructions to do an add instead of one. Hardcore techies will call this "slow," but that's using a crazy frame of reference. Remember, you already can do 80-bit floating point math all all existing x86 processors.
Conclusion: The benefits of moving from 32 to 64 bit integer operations are not worth the cost.
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!
What do you mean "of course desktop use has no need for a 64bit machine"? That is so wrong.
The 4GB limit of address space is a real pain right now. Anyone doing video sees it all the time. Don't confuse the limit of address space with a limit on physical memory.
We generally DON'T need >2GB of physical memory
We generally DO need >4GB of address space and we need it NOW!
Any extra physical memory needed by programs is going to be small. AMD has said that 64-bit code is ~15% bigger than 32-bit code. Hence if you're using 512MB now you could get the same physical usage with about 640MB.
The biggest advantage of 64-bit x86 is, IMHO, the enormous address space (aka virtual memory or linear addresses). All this chatter about PAE/AWE is just off the mark and wrong. PAE does nothing for the address space, it just banks physical like the old expanded memory - and its slooooow.
- 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).
intel are so far behind the times that sometimes I think they're moving backwards.
my sun workstations have been 64-bit for years.
but intel and their derivatives have always performed poorly as well. the difference between a 1GHz and a 2GHz intel is not what you'd expect.
and intel/amd chips generate more heat than my oven.
they're the only chips on the planet that do this. doesn't this tell the stupid consumers of these chips that there's something wrong? or do we just live in a world driven by blind users? I guess it's a microsoft world.
start backing companies that know what the word innovation is. not some two bit company who are still adding silicon to 20 year old architecture to keep it "current."
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
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.
The bit count is not itself a power of 2. Notice we don't have 3-bit, 9-bit, etc. computers. If you just suffix with h, everything should be left justified. Eh? Ah.
I actually just got back from a presentation by AMD here at UIUC (and I won a free t-shirt, too). They oulined the whole hammer architecture and how it's going to be a good thing. By putting the north bridge/memory controller on the CPU die, they're able to cut the DRAM latency by 20% over Athlon! Anyone who's designed computer architectures knows that 20% is HUGE! It only takes 54 clock cycles to complete an instruction cycle, including memory access; if there's a cache hit it was around 30. Actually, the memory read process is started in parallel with the cache hit/miss test and then canceled if there's a hit. Memory bandwidth is also going to get pretty ahead of Intel. AMD is really going to step ahead of Intel with the new hammer architecture. In the future...multiple cores on a single die. That means a single chip, multi-processor system. That'll be huge for the server market! Tech talks are fun!
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?)
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.
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?
Joshu: What is the true Way?
Nansen: Every way is the true Way.
J: Can I study it?
N: The more you study, the further from the Way.
J: If I don't study it, how can I know it?
N: The Way does not belong to things seen: nor to things unseen.
It does not belong to things known: nor to things unknown. Do
not seek it, study it, or name it. To find yourself on it, open
yourself as wide as the sky.
- this post brought to you by the Automated Last Post Generator...