Forgot your password?
typodupeerror
AMD Hardware

64-bit x86 Computing Reaches 10th Anniversary 332

Posted by Unknown Lamer
from the long-live-athlonmp dept.
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.
This discussion has been archived. No new comments can be posted.

64-bit x86 Computing Reaches 10th Anniversary

Comments Filter:
  • by cold fjord (826450) on Monday April 22, 2013 @06:52PM (#43520267)

    ...for being delivered from Itanium and 32bit x86.

  • by iggymanz (596061) on Monday April 22, 2013 @06:57PM (#43520325)

    AMD may have helped create the x86-64 market, but now it's getting killed by it. soon Intel will be the only major player. ARM market is AMD's only hope.

    • by sayfawa (1099071) on Monday April 22, 2013 @07:17PM (#43520495)
      The next console generation disagrees. Sony and MS are both using AMD.
    • by KiloByte (825081)

      AMD smokes Intel in performance/price for most stuff that can be parallelized. It's only single thread performance where Intel wins.

      • by Kjella (173770)

        AMD smokes Intel in performance/price for most stuff that can be parallelized. It's only single thread performance where Intel wins.

        On CPU prices alone, yes... but they're also struggling on performance/watt which translates into performance/$ both in power supply and cooling, which is a fair bit of the cost if you're running big, massively parallel jobs that engage all the cores over long periods of time. Anandtech simply summarized it like this [anandtech.com]:

        Power consumption is also a big negative for Vishera. The CPU draws considerably more power under load compared to Ivy Bridge, or even Sandy Bridge for that matter.

        Every dollar AMD loses on the power bill is of course another dollar Intel can charge extra for a more efficient processor.

        • There's motherboard cost too, you can run an i7 on the cheapest motherboard
          But with an FX 8350 or lower, using the cheap 760G boards leads you to trouble because the VRM circuitry can't handle above 95 watts. Many buyers unknowingly make that mistake and so end up with a great FX CPU underclocked at 800MHz, or it works fast but throttles down and stutters when you do something demanding enough with it.

    • by WD (96061)

      My 16-cores-per-processor servers question your statement. I don't think any other vendor beats AMD on the core density aspect.

    • by tlhIngan (30335) <.slashdot. .at. .worf.net.> on Tuesday April 23, 2013 @12:49AM (#43522219)

      AMD may have helped create the x86-64 market, but now it's getting killed by it. soon Intel will be the only major player. ARM market is AMD's only hope.

      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.

    • by gl4ss (559668)

      AMD may have helped create the x86-64 market, but now it's getting killed by it. soon Intel will be the only major player. ARM market is AMD's only hope.

      not this shit again.

      amd doesn't own any plants, so how would be licensing an arm design and having it contract manufactured save them ?? how the hell?? what would be the amd business and research in that situation?? who the fuck would buy them??

  • "worked out" (Score:2, Insightful)

    But it worked out in the end.

    Yes, mostly due to the fact that we needed a way to get past the 4GB memory limitation, and not because we gave a damn about whether the processor was native x64 or not. AMD has had some great ideas, but they've almost always shorted themselves on the implimentation, leaving the field wide open for Intel to come in with a better offering and take the lion's share of the profit.

    • by Kjella (173770)

      AMD has had some great ideas, but they've almost always shorted themselves on the implimentation, leaving the field wide open for Intel to come in with a better offering and take the lion's share of the profit.

      Well AMD can't magically just "be big" and even when they were kicking Intel's ass fab capacity means you can't take over this market overnight. Intel could afford to gamble on things like Pentium IV and Itanium, while still working on entirely different lines like Pentium III-M that was the basis for the Core processors and Atom which has denied AMD much revenue on the low end. That is the sort of thing AMD never could afford to do, they had to design a jack-of-all-trades and hope that through Intel's inep

    • Re:"worked out" (Score:5, Insightful)

      by Dawn Keyhotie (3145) on Monday April 22, 2013 @11:11PM (#43521817)

      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.

  • by Anonymous Coward

    XP x64, Microsofts ginger step-son of an OS. Ignored and dropped like a hot potato as soon as they could.

    You couldn't get drivers for half the stuff, even MS didn't provide their own software and lots of 'free for home, pay for commercial' stuff would detect it as 2003 Server and refuse to run/install.

    Somewhat of a shame really as it wasn't a bad OS.

  • by Relic of the Future (118669) <<gro.skaerflatigid> <ta> <selad>> on Monday April 22, 2013 @07:37PM (#43520663)
    When AMD gave a presentation to my processor design course (not coincidentally about 10 years ago) one of the presenters said that one of the most surprising speed-ups for 64-bit code came from just having 16 real general purpose registers to work with. Even though register renaming lets you smooth over them, it meant all those extra load and store ops (that RR would identify as waste and work around) now didn't need to be in the code at all. It turned out to be rather non-trivial for one of their test apps.

    So those 32 extra bits of memory addressing are nice. But don't forget about that 1 extra bit for identifying registers!

    • by Darinbob (1142669) on Monday April 22, 2013 @09:25PM (#43521343)

      And this is something people who've worked on RISC chips have known for ages. The x86 system architecture is essentially stuck in the early 80s. The 386 was just a simple extension on top of 286 model, nothing really fundamentally changed, you still had limited number of registers each with at least one specialized purpose. Maybe MMX and similar stuff fixed that but you couldn't rely on everyone's PC to have the instruction set you compiled it for.

      Intel was stuck supporting a very popular CPU with an instruction set that they knew was outdated, and they even tried having replacements for it that failed to gain acceptance. The reason this Opteron caught on was because it was backwards compatible with x86, not because it was the first thing to try to break out of the mold. And 386 was designed to be compatible with 286, which was designed to be compatible wiht 8086, which was designed to be compatible with 8085, which is compatible with 8080, which is compatible with 8008, which is compatible with 4004, which was the first commercially available microprocessor... (and all of those retain the original accumulator A register)

    • > one of the presenters said that one of the most surprising speed-ups for 64-bit code came from just having 16 real general purpose registers to work with.

      Yeah, this has been known for ages. The technical term is called "register spill"* in compiler land.

      * See: http://en.wikipedia.org/wiki/Register_allocation [wikipedia.org]

      i.e. A compiler tries to optimize register usage by trying to reuse temporaries and minimize load/stores since memory is extremely SLOW compared to registers/L1/L2/L3.

      Here's a practical example. Let

  • x32 ABI (Score:5, Informative)

    by Chirs (87576) on Monday April 22, 2013 @07:49PM (#43520763)

    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.

    • by w_dragon (1802458)
      You mean all the good stuff except the ability to access more than 4GB of RAM.
      • by KiloByte (825081)

        except the ability to access more than 4GB of RAM

        3GB typically. That limit applies only per process, and it's pretty rare for a typical user to have a single process that big.

        Then, you have netbooks and/or vserver hosting where the entire [virtual] machine doesn't have that much physical memory.

        x32 is also noticeably faster: over i386 for anything that wants registers, over amd64 for anything with more pointers than CPU's cache. Benchmarks vary wildly, but figures around 7% faster than amd64 are typical.

        • 3GB typically.

          AIUI an x86 process running on an x64 linux kernel gets damn near 4GB of usable virtual address space. I presume the same applies to x32 processes running on that same kernel.

          On a 32-bit kernel as you say 3GB is typical. There were "4G/4G" patches at one stage to increase this but afaict they never made it into mainline.

          • by BitZtream (692029)

            A 32 bit app can't possibly have access to a full 4GB of ram. Doing that prevents you from having any way to interface and pass data two and from the kernel. That 1GB of RAM at the top of the address space was where your kernel pretended to sit, so apps could talk back to the kernel and read data from the kernel.

            Unless you remove the kernel interface, you can't remove the address ranges used by the kernel.

            You can make them smaller, but there are limits, certainly can't go below page sizes.

    • Re:x32 ABI (Score:4, Informative)

      by KiloByte (825081) on Monday April 22, 2013 @08:14PM (#43520939)

      kernel and compiler support is there, not sure about all the userspace stuff.

      Just debootstrap it from Daniel Schepler's repository [debian.org]. Most of the work has since moved to official second-class repositories (AKA debian-ports), but because of the freeze, you want both, So after debootstrapping, echo "deb http://ftp.debian-ports.org/debian [debian-ports.org] unstable main" >>/etc/apt/sources.list and you're set.

  • by raymorris (2726007) on Monday April 22, 2013 @10:25PM (#43521593)
    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.

: is not an identifier

Working...