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."
Well, the industry can always revert to what Apple did if it isn't possible. Make "Fat" executables. ia-64, ia-32 and x86-64 in one executable. Sure, the binaries will be bigger, but with harddisk prices nowadays I don't believe disk space is really an issue :)
My understanding of the situation is that in long mode all your pointers etc are 64bit values and you don't get the extra registers without being in long mode. This means that unless you have compiled for 64bit pointers your code won't run in 32bit mode because the size of the pointers will be wrong. AFAIK the 64bit mode isn't a cpu flag which can be tested for like the SSE/SSE2 instructions, but a mode like Real/Protected mode. Perhaps your process may be able to switch mode but I doubt it. The other possibility of course is that you write byte compiled code which will run in the native x86-64 runtime.
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
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
"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.
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'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/
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
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.
Obviously you didn't bother reading the article before posting did you? I guess I shouldn't expect that though.
While it is true that 32-bit x86 chips can address 36-bits of memory using Intel's PAE, they do so using a really ugly hack. It was a really ugly hack back in the 16-bit x86 days, and it's still an ugly hack now.
AMD's solution is the right one, a true flat 64-bit address space. 64-bit integers aren't particularly important, it's quite rare that an application needs 64-bit integers, and when they do they can easily be handled with two 32-bit integers (albeit at a significantly reduction in performance as compared to true 64-bit integers). 64-bit addressing is what x86 is all about. Well, that and clearing up a few of the remaining problem spots in x86, ie doubling the registers and getting rid of some mostly-useless modes.
Does this chip support tcpa (and thus palladium) ? I think this is a kind of an important detail on the new cpu.
It does when buying all new hardware is MUCH less expensive than buying all new software.
If buying a new machine means you need to replace every single piece of software you use, possibly losing access to old data in the process, most ppl are just not going to buy it.
-1 Uncomfortable Truth
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?)