Slashdot Mirror
64-bit x86 Computing Reaches 10th Anniversary
illiteratehack writes "10 years ago AMD released its first Opteron processor, the first 64-bit x86 processor. The firm's 64-bit 'extensions' allowed the chip to run existing 32-bit x86 code in a bid to avoid the problems faced by Intel's Itanium processor. However AMD suffered from a lack of native 64-bit software support, with Microsoft's Windows XP 64-bit edition severely hampering its adoption in the workstation market."
But it worked out in the end.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
My 32 GB of RAM, absolutely essential for my work, laughs at your "memory management" bullshit.
Life needs more saving throws.
MIPS and Alpha ask power pc to get off their lawn.
Do you even lift?
These aren't the 'roids you're looking for.
Most programs still don't need to work with numbers larger than 4 billion on a regular basis, so native 32-bit ints are just as fast as native 64-bit ones.
Most programs still don't need to map more than 2GB (not 4GB; in fact not even quite 2GB) at once, so there's no pressing need for 64-bit pointers.
Software does take advantage of the fact that you can fit twice as many 32-bit values into the standard x86 registers if the registers are 64 bits wide, in the same way that you can stuff two 16-bit ints into EAX on a 32-bit system if you want to. However, the performance gains from doing so end up in conflict with the reduced cache coherency of larger binaries (bigger instructions) and possibly larger (less well-packed) data, resulting in more frequent cache misses. That's why the perf gains are typically very modest, although it really depends on the application.
Where 64-bit does become really valuable is working with very, very large amounts of sequential data (want to allocate a 10GB array? Can't do that on x86, no way no how). That's hardly a typical requirement right now (although I wrote a program a few weeks ago that needed to do it). However, it's getting closer. Additionally, while clever memory mapping can allow a 32-bit process to access over 4GB of RAM (just not all at the same time), there is a (small) performance impact associated with the need to be constantly re-mapping that memory.
The other area where 64-bit really helps is with security, specifically exploit mitigation. High-entropy ASLR in recent versions of Windows and some other OSes randomly places 64-bit aware executables and their various data regions across their entire 64-bit address space. This not only makes it completely impossible to correctly guess the address of any given bit of code in memory, it also makes spraying (heap spray, JIT spray, etc.) attacks completely infeasible; to cover even a tenth of a percent of the address space, you'd need to spray 16 million gigabytes of data. That's not only quite impractical at modern CPU speeds (even on a blazingly fast CPU and done in parallel, it would take a week or more), it also is far more memory (physical or virtual) than any modern computer will be able to allocate.
There's no place I could be, since I've found Serenity...
The next console generation disagrees. Sony and MS are both using AMD.
Free the Quark 3 from asymptotic confinement! Bring your charm! Don't get down! All colours and flavours welcome!
do you? for average PC applications (browsing the web, e-mail, office documents) 64 bit gives no advantage. for the above-average applications (multimedia creation/editing, CADD, running multiple VMs, ) it's very helpful.
1) Yes, I do.
2) You are so wrong that it's actually funny.
So those 32 extra bits of memory addressing are nice. But don't forget about that 1 extra bit for identifying registers!
Those who fail to understand communication protocols, are doomed to repeat them over port 80.
And for those that want the best of both worlds, there is the x32 ABI, which uses all the good stuff from x86-64 (more registers, better floating-point performance, faster position-independent code shared libraries, function parameters passed via registers, faster syscall instruction... ) while using 32-bit pointers and thus avoiding the overhead of 64-bit pointers.
They're working on porting Linux to the new ABI...kernel and compiler support is there, not sure about all the userspace stuff.
In our algorithms lab there were programs that would gain more than 2x when compiled for 64 bit.
A more "real-world" example is when I started in 2005 at my current company. The engineers had 6-month old P4s @ 3.2 or 3.4GHz, running 32bit linux. For a project they used VisualStudio on VMWare and it took over a minute to compile the project. The company allowed engineers to choose their hardware, so I built an Athlon 64 @ 2.2 or 2.4GHz and I had it run 64bit SuSE. I remember the shock and awe from the first time I tried to compile the project under VMWare - a little more than 10 secs - the engineer next to me had his jaw drop. Of course most of the engineers immediately requested to switch to 64bit machines. I am not sure why it made such a difference in that application - perhaps the 16 general purpose registers come in really handy in this scenario? Of course it didn't help that the P4 was slower in everything (funny how at the time very few reviews really clarified this), but not order of magnitude slower...
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
I think if you understand how truly horrifying PAE is, you would have no doubt at all that 64 bit platforms were the way to go. There's a lot of memory management cruft in the Linux kernel that x86_64 eliminates.
x86_64 also slipped in a few much needed enhancements to the ia32 architecture, including some extra general purpose registers.
http://en.wikipedia.org/wiki/X86-64
Is this still Slashdot? Nobody mentioned that Linux supported x86 64 in 2001, before it was even released, while Windows was stuck at 32 bit for another four years.
PAE is more or less old school segmentation. You can't say 'it has a 3% slow down' because it has 0 slowdown if that particular page is already in memory, and if not ... it has the same 'slowdown' as an other paging operation plus a fixed number of cycles. So if you're dealing with tiny amounts of 'more than 2/3gb' then the overhead is a lot higher than if you're mapping out 2GB on every window change. PAE is just another form of paging. It is slower, but you're making numbers up from nothingness.
The interger math performance of the processer has nothing to do with it being 64 bit. Most (All now?) x86-64 processors internally will process 2 32 bit numbers in the same span as a 64 bit number if properly optimized by sending the 32 bit values through together. 64 bit code using less than the OS max for 32 bit code is actually slower than 32 bit code due to the increased pointer sizes wasting the processors registers filling them with 0s.
You really have no idea how processors work. While nothing you said is illogical, it is still in fact wrong in every account. Under the hood, processors don't work anything like they do on the surface.
Other processors also do other weird things. I have an 8 bit CPU that can handle 32 bit numbers in a single clock cycle, exactly like it does 8 bit numbers ... and the neat thing ... it can do 2 16 bit numbers in a single clock cycle! Why? Because the processor as I see it from a software developers perspective isn't anything like the actual hardware doing the work. Processors have translation units in front of them to provide you with one look while allowing themselves to rewire the backend in all sorts of different ways.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
WRONG on many levels. Yes, we had to get past the 4GB memory limitation, but there had been, and still were at the time, several other true 64-bit microprocessors around when AMD introduced the Opteron: Alpha, UltraSPARC, MIPS, PowerPC, and yes even IA-64. (not to mention IBM POWER and zSeries.) But they all had the fatal flaw of NOT being compatible with the Intel 32-bit x86 processors and off-the-shelf Windows software. Only Opteron had that, and that compatibility was so critical that Intel was grudgingly forced to adopt the x86-64 instruction set.
So, you may say, why didn't AMD take the IT world by storm? Because of 1) AMD was not Intel, and never could/would be; 2) Intel was paying manufacturers NOT to offer ANY AMD based systems with marketing kickback agreements; 3) Intel would punish any manufacturer who did offer AMD systems with exorbitant price hikes on the Intel parts they did sell; 4) All this was taking place during the Bush years of federal laissez-faire non-enforcement policy, giving Intel free rein on those practices; 5) Prejudice against AMD in the IT industry was widespread, and still is; 6) few people saw or acknowledged the need for a flat 64-bit address space; 7) those that did have the need for 64-bit software were forced to spend exorbitant amounts of money for RISC workstations, which motivated them to look down their nose at commodity PCs, even if they were 64-bit; 7) Chicken-and-Egg syndrome (no volume 64-bit hardware, thus no volume 64-bit software, thus no need for volume 64-bit hardware).
So AMD did not "short themselves on implementation". Their architecture was state of the art, and kicked both 32-bit Pentium and non-compatible IA-64 in the nuts. They had all of today's advanced hardware features years before Intel: x86-64 architecture; Hyper-transport to replace the front-side bus bottleneck and enable point-to-point CPU links; and on-board memory controllers. AMD was not able to block Intel from poaching their features because of the pre-existing patent cross-licensing agreements. And anti-monopoly enforcement was practically non-existent at the time (and not much better today).
Of course, not of this is meant to imply that AMD was not partially or even mostly responsible for their troubles. They were (and still are) horrible at executing their own roadmaps. They were (and still are) horrible at marketing to consumers. They were (and still are) horrible at manufacturer relations. They were (and still are) unable to make a sane strategic decision if their life depended on it. They were (and still are) perceived as the el-cheapo Intel-knockoff copycat instead of pioneering leaders in their field.
So yeah, AMD is a hot mess, but there is plenty of blame to go around.
"The only good windmill is a tilted windmill."
x64 has twice as many registers. That alone means less having to move stuff in and out of memory, so that will improve the speed when compared to 32 bit applications. 32 bit x86 has only 4 truly general purpose registers. x64 adds another 8 64 bit registers.
Oolite: Elite-like game. For Mac, Linux and Windows
Intel won't let AMD die. In fact, AMD is right where Intel wants them to be - big enough to ward off government regulators, small enough to not be a huge pain in the rear. Intel and other large companies are scared of government regulation and monopoly declaration, and we do know that Intel has committed enough sins that if the regulators look hard enough, they can make a case to break up Intel. Including separating the ASIC design and foundry parts (and we know Intel has a LOT of foundry capacity). And I'm sure Intel's shareholders would rather give up some revenue to ward off the much bigger hit that would happen when the government regulators step in.
It's entirely possible that Intel has a bunch of "AMD rescue" plans - ranging from simple "let's just buy up all of AMD's CPUs and bury them" to more elaborate schemes. Of course, Intel cannot directly fund AMD. Perhaps Intel could give AMD some patents in an emergency.
Heck, you could argue that Intel told Sony and Microsoft to buy AMD chips - it gives AMD a nice steady income for the next few years. Intel could've used their extensive fab capacity to make custom chips for the consoles (much more easily than AMD can), but you can bet an opportunity like this to help prevent AMD from keeling over was just perfect.
And no, this isn't unusual in the business world. What you see as competitors can have all sorts of incestuous relationships amongst themselves - it's not unknown to have competitors to buy parts from each other. And you can bet Apple, Google, Microsoft, Samsung and others are far more chummy to each other than patent lawsuits or settlements will imply. There's enough back room deals and arrangements that really hide the interdependence on each other they all have.
it's an easy choice unless you absolutely need 16-bit support.
The annoying thing being that an x86-64 processor in long mode can, in fact, run 16-bit protected mode code (like essentially all actual Windows 3.x programs) with the same compatibility sub-mode that runs 32-bit code. It's merely that Microsoft decided they didn't want to bother supporting it.
That this can be done is easy enough to prove; take a Win16 app and run it in WINE on 64-bit Linux.