Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
AMD Hardware

AMD64 Preview 290

Posted by timothy from the progress dept.
Araxen writes "Over at Anandtech.com they have an interesting preview of AMD's 64 bit processor on a Nforce3 mobo. The results are very impressive with the Anthlon64 beating out Intel's P4 best processor soundly in their gaming benchmarks. This was only in 32-bit mode no less! I can't wait for 64-bit benchmarks come out!"
This discussion has been archived. No new comments can be posted.

AMD64 Preview More

AMD64 Preview

Comments Filter:

  • Opteron Benchmarks, not Athlon 64 (Score:5, Informative)

    by ultor ( 216766 ) on Saturday September 06, 2003 @03:21PM (#6889042) Homepage
    The benchmarks are from a 2ghz Opteron, not an Athlon 64. It is intended to give an example of the performance from the new chip. Unfortunately, upon introduction, only the Athlon FX, running on ECC memory will be capable of using dual-channel memory. And from what I've heard, this cpu will cost in the vicinity of $600+. The first non-ECC dual-channel platform will be introduced in 2004.

    • But is it representative? (Score:2, Interesting)

      by eddy ( 18759 )

      While true, isn't the whole point of this "preview" to demonstrate the true Athlon64 performance without breaking the NDA by actually publishing Athlon64 benchmarks?

      I'm guessing they have access to Athlon64 hardware, and simply "tweaked" the Opteron until ut produced similar enough results to be published as a "preview" -- Since those can be published. It's almost a little like what AMD did with their PR rating, which is officially based on the Thunderbird line, but everyone compare it to the P4 core freq

      • (am I the only person who got several pages without content in the preview?)

        I read this article this morning long before it hit slashdot and didn't have that problem. What it likely was is that several of the pages were nothing but images (charts) and poor anand was suffering a slashdotting when you tried accessing them. Hence, nothing came up. Might want to try again when the frenzy dies down some.
    • The top end chip might be in the $600 dollar range, but the cheaper chips will be significantly less than that.

      For comparison, the 1.8GHz Opterons are in the $460 range on Pricewatch [pricewatch.com]. So the A64's will have to be somewhat lower than that in price. (Unless they skip 1.8 altogether)

      Also, for many benchmarks, dual-channel memory isn't that important. What is most important with the A64's (and Opterons) for desktop application speed is the on-chip memory controller. This gives these chips dramaticall

  • Not an Athlon64, but an Opteron (Score:5, Informative)

    by doormat ( 63648 ) on Saturday September 06, 2003 @03:23PM (#6889058) Homepage Journal
    Anandtech is only comparing single processor Opteron performance against everything else, no infact, Athlon64 performance. The primary difference is that the Opteron has a dual channel memory subsystem, whereas the Athlon64 has a single channel system. This difference will have an affect on performance.

    • Re:Not an Athlon64, but an Opteron (Score:5, Informative)

      by heli0 ( 659560 ) on Saturday September 06, 2003 @03:40PM (#6889161)
      There will actually be two lines at launch. The 940-pin Athlon64FX(1-way Opteron) will have dual channel DDR while the cheaper 754-pin Athlon64 will have single channel DDR.

      [hardocp.com]
      Athlon64 Showing Up
      Pricing for Athlon 64 leaks: 939 pin chip won't be compatible with 940 CPU [theinquirer.net]

    • Re:Not an Athlon64, but an Opteron (Score:5, Informative)

      by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Saturday September 06, 2003 @04:30PM (#6889428) Homepage
      Your comment is somewhat missleading. There are TWO Athlon 64s being launched (or as Overclockers.com called them the "Opteron that's not an opteron but is an opteron" and the "operton that's really not an opteron" or something like that). Annandtech compared the equivelent of an Athlon64 FX, not an Athlon64. Here is the skinny:

      Athlon64 FX
      This is a 1xx opteron. It's still dual channel, and it uses ECC memmory (for now?). This is the "performance" part, the high end one. If we're trying to find who has the fastest CPU, this is the one to test. Their tests are quite valid for this, IMHO.

      Athlon64
      This is the "budget" Athlon64. It only has once memory channel, I don't know if it has ECC or not. Yes, this will be slower, but it will also be cheaper and the motherboards for it could be cheaper too (since it doesn't have that second memory channel).

      So, I think that this is a very important article. Look how fast an Opteron/Athlon64 FX is compared to a P4. A 2 Ghz Opteron/Athlon64 FX is beating a 3 Ghz P4. This is all on a 32 bit os and software. When you run 64 bit software that knows about all the extra registers and can do 64 bit math nativly should it need to, the computer will be fast. Tim Sweeny (spelling?) said that native versions of UT2003 (or something) was running up to 20% faster on x86-64 without optimisations; just from going to 64 bit mode. And for most of us the fact that it can manage over 4GB of mem easily for now is only iceing on the cake.

      AMD has a great processor. I can't wait to see more info on these things. The fact that it does so well in 32 bit mode is important since you currently can't get Windows for the processor (there is no x86-64 version of Windows out yet). If it was a great processor, but you were forced to get terrible performance if you bought one for 6+ months (becuase it wasn't good with 32 bit software like windows and what you run), would anyone buy it? This thing is faster today, and should only get faster when you run native software. I'm saving my pennies (and yes, I know it will take a lot of pennies ;).

      • Re:Not an Athlon64, but an Opteron (Score:4, Informative)

        by Jeff DeMaagd ( 2015 ) on Saturday September 06, 2003 @11:45PM (#6891351) Homepage Journal
        I don't know how this fits with your listing, but it looks like there might be another derivative budget chip at or below A64 that might not have a 64 bit mode at all:

        [theregister.co.uk]
        AMD to ship Athlon 64s as Athlon XPs

        I do find it amusing that people are commenting how good something is or is not before the damn product has been released, particularly when there is so little hard information on what it will really amount to.

        So far one difficulty I see is the lack of Hammer boards that have AGP _and_ PCI-X slots or at least 64 bit/66MHz PCI slots, and they commented on this in that review last I checked. I think part of the assumption was that because these systems are for servers, AGP isn't needed, or if AGP is needed, it was assumed that PCI I/O slots weren't that critical.

  • Will it be secure? (Score:5, Interesting)

    by samjam ( 256347 ) on Saturday September 06, 2003 @03:31PM (#6889104) Homepage Journal
    When are some of these newer processors going to implement the executable permissions bit in the MMU so that the STACK can be NON-EXECUTABLE (ok I know some trampoline stuff needs executable stacks, well they can ask for it where needed by setting the executable bit for a small region)

    And when are some of these new processors going to be fully virtualizable? I'm talking about PUSHF and POPF generating exceptions like directly setting the interrupt flag does.

    Think how easy plex86 would be to run on a processor that did this properly?

    Code-morphing Transmeta (come one!), AMD (maybe?) Intel (no chance?)

    Sam

    • Re:Will it be secure? (Score:5, Funny)

      by Amoeba ( 55277 ) on Saturday September 06, 2003 @03:51PM (#6889214)
      The sad thing is I understood everything you just said.

      My God, I *am* a geek.

    • AMD64 already has non-executable pages. (Score:5, Informative)

      by tamyrlin ( 51 ) on Saturday September 06, 2003 @06:28PM (#6890017) Homepage
      Quoting the AMD64 Architecture Programmer's Manual Volume 2: System Programming:

      "The NX bit in the page-translation tables specifies whether instructions can be executed from the page."

      So non-executable pages are already present in AMD64.

  • 64bit performance gains... (Score:5, Informative)

    by Natalie's Hot Grits ( 241348 ) on Saturday September 06, 2003 @03:33PM (#6889114) Homepage
    Before anybody starts talking about how little 64bit cpu's actually increase performance, let me tell everyone what 64 bit mode will actually bring to the table over the Opteron/Athlon64 32 bit modes:

    1) more registers. This will get us fair performance increase from the start, as compilers will have more registers to work with when doing calculations on multiple pieces of data.

    2) support for larger system memory sizes. This won't help you in video games, but it will help you doing high end photoshop, and other applications (provided you spend the money to get more memory put into your system)

    3) native operations on 64 bit data. Typically, when someone wants to do operations on a 64 bit integer in a 32 bit CPU, you have to split up the work in software. Now with 64 bit registers, you will be able to do operations on 64 bit integers in the same time as it takes to do the same operation on a 32 bit integer.

    4) when using native 64 bit mode, certain legacy instructions of x86-32 are depreciated. This is a cleanup for the x86 ISA, which in the past has contained literaly EVERYTHING that the previous generation of CPU supported. AMD's x86-64 ISA eliminates these legacy features and moves them into firmware emulation (don't worry, it won't degrade any modern 32 bit code, just terribly outdated stuff from the 386 days, which doesn't need 2GHz of power in the first place)

    On top of these performance enhancements that 64 bit mode brings you, you get all of this just because you are using AMD's Opteron/Athlon64 CPU:

    1) Dual channel DDR Memory interface, with memory controller on the die of the CPU. This reduces latency and improves memory bandwidth so dramatically that even Intel's off die memory controller can't keep up (this is why video games are so much faster on the amd64 platform than on athlon-32 platform)

    2) HyperTransport bus to the south bridge, which will give high bandwidth access to the PCI bus, PCI-X, and other IO intensive controllers. Eventually AGP slots will be phased out for PCI-X slots which will be universal for both video, and other devices.

    3) when using multiple CPU's in the same system, the new AMD-64 platform gives you dedicated memory bandwidth to each CPU installed. On the intel and athlon-32 platforms, all the CPU's in the system shared the same memory controller which runs either single or dual channel DDR anywhere from 266MHz - 400MHz.

    • Re:64bit performance gains... (Score:5, Informative)

      by p3d0 ( 42270 ) on Saturday September 06, 2003 @03:46PM (#6889186)
      Nice summary. I would only add a couple of things:
      • 64-bit math on IA32 requires register pairs. With 8 GPRs, one of which is reserved for the stack pointer, that means you can only keep 3 long-longs in registers. On AMD64, even if you dedicate another register to the frame pointer, you can still get 14 long-longs in registers: almost a factor of 5 improvement.
      • The benefits from the memory subsystem will be offset by the fact that objects containing pointers will be twice as big as on IA32. That means objects could have twice the cache footprint and twice the memory bandwith requirements.

      • The benefits from the memory subsystem will be offset by the fact that objects containing pointers will be twice as big as on IA32. That means objects could have twice the cache footprint and twice the memory bandwith requirements.

        Except that pointers make up only a small fraction of the code footprint of an executable - most of it is ints, which still are 32-bit by default on x86-64. In general you can easily minimize the number of pointers in code by doing math (i.e., with 32-bit ints) on one base poi

        • Re:64bit performance gains... (Score:5, Informative)

          by p3d0 ( 42270 ) on Saturday September 06, 2003 @05:32PM (#6889730)
          I meant data objects, as in object-oriented programming. Not object files. OO data tends to have a lot of pointers.

          Having said that, object files will be bigger too. I'm not sure where you're getting your 10-15%; have you actually checked? I don't have access to our AMD64 boxes right now so I can't take a look at the object files, but I think the difference could easily be more than that for object-oriented code, for a number of reasons:

          • Probably 2/3 of the instructions in hot code will need a REX prefix, either because they use registers r8-r15, or because they manipulate addresses.
          • Only mov instructions can use an 8-byte immediate. Anything else that needs an 8-byte immediate must load that immediate into a register first with a 10-byte mov instruction, possibly spilling whatever was in that register. We could be talking about 3 extra instructions totalling maybe 18 bytes on an instruction that used to occupy maybe 6 bytes. Class tests in a polymorphic inline cache are particularly affected by this. Also, relocations (ie. jumps between different DLLs) must be 64 bits because there's no reason to think DLLs will be loaded within a 32-bit offset of each other.
          • Autos that are pointers now occupy twice as much stack space, making your stack frame that much less likely to fit within an 8-bit signed offset (ie. 127 bytes). That means you can't use [esp+12h] addressing to access your locals, but rather [rsp+12345678h], which requires three extra bytes (not to mention the Rex prefix). Highly optimized functions often have lots of variables, especially after inlining, and in OO code, lots of the variables are pointers, so this one could hurt.
          • Similarly, the AMD64 linkage convention on Linux has 6 parameters passed in registers (while IA32 has none) which also makes the stack frame bigger. This can be mitigated by using a frame pointer, but if you don't dedicate a register as a frame pointer, than you need to access your parameters with the stack pointer (rsp), and the parameters are always at the largest offsets from rsp. Result: parameters are likely not to be reachable with an 8-bit offset from rsp.
          If I had to estimate off the top of my head, I'd guess code would be more like 25% bigger, while OO data could be as much as 50% bigger. (Remember that each object contains a pointer to its class or vft, and many object fields are pointers.)

          • Re:64bit performance gains... (Score:4, Insightful)

            by Ninja Programmer ( 145252 ) on Sunday September 07, 2003 @12:58AM (#6891543) Homepage
            Object code side with *NOT* be bigger -- it should be *SMALLER* if anything:
            • Pointers inside objects occupy run-time memory from the *HEAP* -- i.e., they don't have any presence in the object file.
            • The use of REX to access r8-r15 is the register based alternative to using a SIB byte, and offset for an [ebp+offset] encoding for directly accessing the stack. I.e., paying the cost of an extra prefix byte saves in both execution speed and actual code size versus the spill/fill style or direct stack based alternative.
            • Auto areas that are larger than 256 bytes because they are filled with a bazillion pointers are indicative of more serious program design flaws (that people don't generally have) than the statistical potential of loss from using far offset values from it. This is an extremely marginal case at best.
            • I don't understand your linkage complaint -- the more parameters passed in registers, the fewer that will end up on the stack.
        • Most of it is ints? I thought something like 50% of the average executable was either a jump, a conditional jump, or a test...

      • Re:64bit performance gains... (Score:4, Interesting)

        by timeOday ( 582209 ) on Saturday September 06, 2003 @05:18PM (#6889663)
        The benefits from the memory subsystem will be offset by the fact that objects containing pointers will be twice as big as on IA32. That means objects could have twice the cache footprint and twice the memory bandwith requirements.
        I wonder if it will be possible to use 32 bit pointers within the X86-64 isa? This would save memory on pointers but give you access to the extra registers, instructions, and one-whack 64 bit math (which should be great for encryption and compression, without using special mmx instructions).

        I thought I remembered SPARC being able to do this, but it looks like [sun.com] SPARC programs must be compiled with 64 bit pointers to efficiently perform 64 bit arithmetic.

        • I wonder if it will be possible to use 32 bit pointers within the X86-64 isa?

          In a word, no. If you want the extra regs, you get 64-bit addresses. You could always limit yourself to the low 4GB of memory, though. Then you could just omit the REX prefix from loads and stores of addresses, which would have the effect of zero-extending them while they are in regs, while also making the code a bit smaller!

          Incidentally, they seem to have abandoned the terrible name "x86-64" in favour of the much more s

      • Since most applications do not need a 64 bit address range, will it be possible to still use all the juicy 64 bit number manipulation for 64 bit numbers but still keep 32 bit pointers for most things?

        In fact, I think it will be at least 5 years, and probably a decade before the average application needs to use more then 31 bits of address space.

        • Since most applications do not need a 64 bit address range, will it be possible to still use all the juicy 64 bit number manipulation for 64 bit numbers but still keep 32 bit pointers for most things?

          For programs that fit nicely in a 32 bit address space, perhaps you could designate one of the 64-bit registers as a base pointer, and store all the addresses as offsets? This may be cheaper than you think, since we now have 8 additional registers to play with.

          In fact, I think it will be at least 5 years,

    • 2) support for larger system memory sizes. This won't help you in video games, but it will help you doing high end photoshop, and other applications (provided you spend the money to get more memory put into your system)

      How would this not help games? My "Republic : The Revolution" supports only systems with 512 MB of ram or more.

      I think the cheaper the ram becomes the more we'd see programmers making unoptimized memory hogging games and thus games in general would become highly dependent on a large memo

    • 20% Gain (Score:4, Informative)

      by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Saturday September 06, 2003 @04:34PM (#6889456) Homepage
      IIRC, Tim Sweeny said that by recompiling one of the versions of UT (2003 maybe?) for the x86-64 platform without optimizations, they saw up to a 20% performance boost. Now if they were to optomize the code on top of that, they could probably get a little more.

      So even for programs that don't need to use 64 bit math, moving them to the x86-64 platform can speed them up. It won't improve your typing speed in Word, but it can probably speed up most if not all your games if they are simply recompiled.

    • So why didn't Intel do this? (Score:4, Insightful)

      by fm6 ( 162816 ) on Saturday September 06, 2003 @04:53PM (#6889544) Homepage Journal
      Basically, you're saying that this is an important incremental improvement over previous x86 processors. Which describes every new x86 processor right back to the 8088. So you have to ask: why did Intel abandon the incremental approach with the Itanium? It's locked them in as the dominant CPU maker since forever.
      • Probably the corporate politics. Intel has sunk a lot of money and time into the Itanium architecture, almost a decade's worth.

        I'm sure they have plan B's along the lines of AMD's approach, they just don't want to undercut the official stance of "everyone recompile for EPIC".

        • Re:So why didn't Intel do this? Politics (Score:4, Insightful)

          by fm6 ( 162816 ) on Saturday September 06, 2003 @05:17PM (#6889659) Homepage Journal
          Intel has sunk a lot of money and time into the Itanium architecture, almost a decade's worth.
          Well, that explains why they're pushing the Itanium now. But the real question is what they were thinking 10 years ago, when they committed so much to a non-compatible processor. They knew going in that developing the Itanium was going to gobble up a lot of resources. So much so, they had to bring in HP to help. Imagine a project that's so big that Intel can't handle it solo!

          Perhaps somebody was bored with the whole Pentium architecture.

          • Re:So why didn't Intel do this? Politics (Score:3, Insightful)

            by Anonymous Coward
            10-15 years ago, everyone else in the industry thought x86 was a dead end. Massive amounts of investement poured into RISC alternatives like Alpha and PPC.

            Perhaps Intel believed the conventional wisdom and felt they had to eventually drop x86.
            • Good point. Too bad you posted as an AC, so nobody'll see it.

            • Re:So why didn't Intel do this? Politics (Score:5, Informative)

              by afidel ( 530433 ) on Saturday September 06, 2003 @06:22PM (#6889975)
              And conventional wisdom was correct. They just underestimated the power of the entrenched software library. Intel processors since the Pentium Pro have basically been RISC cores with a x86->RISC translator in front. This allows them to ramp up the speed of the core, even change core architectures while still running all the old code. It costs at the fairly small cost of the gates needed for the translation frontend. It has another advantage in that CISC operations take up less room in cache so you get much better utilization out of your expensive cache resources. Intel started the Itanium project for two reasons, HP needed a new flagship chip and they are a large enough customer to sway Intel, and two they were tired of Cyrix and AMD copying their designs so they were going to make a tightly controlled architecture where EVERYTHING was covered by patents and copyright, that way they thought they could have the whole pie to themselves. What they didn't realize is that while they are a big player the only reason people keep using their chips is that they have maintained that backwards compatability path, throw that away and Intel is just another chip maker and others like IBM, Motorolla, etc may look better.
    • 1) more registers. This will get us fair performance increase from the start, as compilers will have more registers to work with when doing calculations on multiple pieces of data.
      I think processors already have alot more than the addressable number of registers, which are used by dynamically remapping the addresses during execution. Sounds ugly, and doing it in the compiler will surely work somewhat better, but it decreases the performance increase we can expect.
      • No, register renumbering doesn't help when you just don't have enough regs. Renumbering is to eliminate unnecessary dependencies between uses of the same architectural register. For instance, renumbering can turn this:

        load r1
        store r1
        load r1
        store r1

        into this:

        load r1
        store r1
        load r2
        store r2

        Then, all these stores can be reordered internally, which would have been prevented otherwise.

        If you don't have enough architectural registers, then the compiler must insert spills to memory, and only s

    • 1) Is NOT an inate property of a 64 bit processor. You could build a 32 bit processor with more registers.

      2) is valid

      3) True but almost no software I use does much 64 bit type processing.

      4) You could do this with a compiler, it the instruction is slow, yu don't save die area because you need to support it in 32 bit mode.

      You missed out the biggest winner, the massive cache on this processor, 1MB I believe, that's a big step up.

      You put a cache that size on a 32 bit Athlon and you will see some big improv
      • You can build a 32 bit processor with more registers, but you can't build a 32 bit x86 processor with more registers, it wouldn't be x86. It's just nice that they took advantage of their break from x86 and added more.

        Any software which deals with data types larger than 32 bits will benefit from 64-bitness. This is most software. Even string operations will speed up, once your libraries are 64 bit.

        You're right about the big cache being hugely significant of course, but it's not the only reason this thing

      • Don't be so sure about the cache. Bigger caches are slower. Make sure you know the cache latency before you claim a bigger cache is better.

        Anyway, some Xeons have a 6MB L3 cache, so 1MB isn't a big deal.

    • Those are good points. Let me now enumerate the disadvatages of 64 bits over 32 bits.

      1) Your data caches will appear smaller (relative to 32 bit code) because your pointers are now twice as big in order to address that nice 64 bit space.

      2) Since your ALUs needs to be twice as wide, they can't go as fast. The ALU path in a microprocessor is very speed critical and is often what dictates the maximum frequency you can run at.

      3) Since your datapath is twice as large, you will inevitably burn more power.

      4)

    • Not just more memory, more address space (Score:4, Insightful)

      by Namarrgon ( 105036 ) on Saturday September 06, 2003 @09:01PM (#6890695) Homepage
      Obviously for some high-demand apps, having >4 GB of memory is a Very Good Thing. But for some apps (especially under Windows), a 64 bit processor can be bring another big benefit to the table: a full 64 bit address space. Obviously this is needed for more memory, but even with only 2 GB of RAM, a Windows app that uses large contiguous areas of memory can run into serious address space fragmentation long before they run out of memory.

      In Windows, you only get 2 GB of address space for your process (WinXP & expensive Win2K Server versions can give 3 GB, which helps). Into this address space is loaded your executable code (including all system DLLs) and your stack (by default 1 MB of address space is reserved for every thread), and these tend to be scattered around a bit, which breaks up the available address range considerably.

      Now if your app needs to allocate large (200+ MB) areas of memory, how many of those do you think you can get from a 2 GB RAM machine? Not enough :-) In fact you may find that as little as 50-60% of your available RAM can be allocated into large chunks, and all the rest is only available as countless smaller fragments. The larger the contiguous RAM blocks you want, the less of them you can allocate.

      With a 64 bit CPU, there's no more problem. The MMU can map scattered pages of your available physical RAM to any contiguous section of the massive 64 bit address range, and you can utilise all the RAM you have in any size chunk you wish :-)

  • This was only in 32-bit mode no less! I can't wait for 64-bit benchmarks come out!

    The above seems to imply that game benchmark results will be better at 64-bit. Now, if those games needed access to many gigabytes of game data, that would be an entirely correct assumption.

    Apart from the utter pointlessness of 64-bit gaming for the coming years because of the comparatively humble data requirements of current games, a benchmark of 64-bit gaming performance (say, its 3D calculation or its AI plotting perform

    • Re:About 64-bit gaming performance (Score:5, Informative)

      by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Saturday September 06, 2003 @03:50PM (#6889209)
      a benchmark of 64-bit gaming performance (say, its 3D calculation or its AI plotting performance) would be mostly a waste of time, as you would see very likely only see an equalling performance at best.

      This would have been the case if IA-32 was a sane architecture. Athlon64 in IA-32 mode has only 8 visible general purpose registers, whereas it has 16 in 64-bit mode. That makes 64-bit mode a win in almost all cases. Technically it would have made sense for AMD to introduce a new 32-bit mode, but it would probably have been bad for marketing.

      • I love it when people act like you can use all eight "GPRs" in x86 as GPRs. Many operations depend on using a specific register, and that includes such mainstays as copies, and mathematical operations. In reality you have four true GPRs and four index registers... well, or considered another way, two long index registers. I know many instructions will let you use those registers for whatever you want, but not all of them will.

        In other words... it's not a sane architecture. But presumably it was easy to im

    • The above seems to imply that game benchmark results will be better at 64-bit.

      With a little tweaking and register optimization, they will be better. You have double-sized registers, and much more general purpose registers. In tight inner loops, being able to complete a loop in 10 vrs 20 clocks makes a hell of a difference.

      Now, if those games needed access to many gigabytes of game data, that would be an entirely correct assumption.

      We are getting to that point. I believe Doom 3's textures are approa
      • Hmm.. you say that having bigger and more registers is going to increase the speed of programs..

        Well, this may be true if the only code running is the game and doesn't transfer double the data from the memory to process (64bits rather than 32).

        However, what happens when the operating system does a context switch or some other exception occurs? The latency from saving the processor context is going to go way up as you have to save far more data to memory and then load the same large amount of data in for t
        • However, what happens when the operating system does a context switch or some other exception occurs? The latency from saving the processor context is going to go way up as you have to save far more data to memory and then load the same large amount of data in for the new context.

          There is no "context-switch" delay. The processor takes exactly the same amount of time doing a context-switch at 64-bits than at 32-bits. Remember that the processor has to do a certain number of clocks per second, and it cann
        • Your analysis is detailed and insightful, and at one time was a big issue. However, today's sheer clock speeds and superscalar pipelines render it far less of a burden. How fast does your OS switch contexts? every few milliseconds? "iostat" on my 1.0 Ghz Athlon t-bird says 351 cs/sec; 1.0/351 ~= 2 ms execution time per context. This is enough time for even the >>tightest>miniscule compared to the time tight loops have at their disposal. This, coupled with the fact that context switches are s
    • What you say is true, if the only improvement of AMD64 is 64-bit support. However, AMD64 also doubles the number of general-purpose and XMM (for SSE, SSE2) registers to 16 of each. This will make many programs run faster, as having 8 general-purpose registers is just not enough. Far too much time is given to swapping data into and out of registers on x86.
      The additional registers is really what I like about AMD64. I couldn't care less about 64bit for now.

  • Athlon64 will be in short supply (Score:5, Interesting)

    by afidel ( 530433 ) on Saturday September 06, 2003 @03:35PM (#6889129)
    or so says Ars Technica. In addition most of the initial shipments will go to motherboard manufacturers for bundling with their boards. I really don't like the idea of that becoming common practice as that much purchasing power will mean tight pricing controlls. Read more Here [arstechnica.com].
    • Well, Intel tried to impose tight pricing controls on a lot of its CPUs. Fortunately, they'd signed second-sourcing contracts with various other companies. They tried to get out of them, but AMD's lawyers were able to persuade the courts that A Deal's a Deal. A damned good thing, 'cause a lot of important changes have been fuelled by commodity-priced CPUs.

      Now the relationship between AMD and Intel may be reversed. Of course, Intel doesn't have a second-source contract for the Athlon64. But what they do ha

  • Intel Itanium vrs. AMD Opteron/Athlon64 (Score:5, Informative)

    by mjuarez ( 12463 ) * on Saturday September 06, 2003 @03:45PM (#6889184)
    Just to set some things straight:

    - Itanium, Intel's 64-bit chip, uses a totally different architecture (EPIC) from the current Pentium x86 line of chips. This architecture is NOT compatible with x86, so that effectively you need a recompile for existing software work on Itanium. There is an EMULATION mode for x86 in Itanium, which is absolutely unusable according to various sources on the Net. You will DEFINITELY not want to run a game on it. Finally, prices for a low-end 1.0Ghz Itanium chip start at approx $800.

    - AMD's Opteron/Athlon64 chips are compatible with everything you are running right now at 32 bits. You can install a complete 32-bit operating system in it, and everything will run just as today, albeit a little bit faster. There is no need for an "emulator". And, of course, you can already use Linux at full-64 bits, available from SuSe, RedHat and Mandrake. Also, Microsoft will release a 64-bit version of XP at the end of the year.

    Marcos
    • What are the real differences in architecture that make it this way? I'm kind of a "reinvent the wheel" type person, so I wonder whether AMD has had to make sacrifices to keep this compatibility. On the other hand, Linus seems to prefer AMD's design.
      • Basically, they extended the x86 architecture again, like Intel themselves did 15 years ago when going from the 286 to the 386 architecture (16 bits to 32 bits). They maintained the current binary compatibility, while extending the registers to double their size, and make additional registers available. Intel completely ignored this possibility since going to Itanium was going to be "so much better". As we have seen, however, that was simply not true.

        Of course, the whole exercise is moot if there is no

  • First Look at Windows XP 64bit for AMD64 (Score:5, Informative)

    by rchatterjee ( 211000 ) on Saturday September 06, 2003 @03:53PM (#6889227) Homepage
    GamePC [gamepc.com] is running a first look [gamepc.com] of Windows XP 64bit edition for the AMD64 (x86-64) architecture.
  • What an annoying page..
    I turn off Flash to squelch their highly annoying
    animated ads and none of their graphs show up.

    • What an annoying page..
      I turn off Flash to squelch their highly annoying
      animated ads and none of their graphs show up.

      Just use the Mozilla Firebird browser and install the Flash click to view [mielczarek.org] plugin. Like the name suggests, you won't see any flash unless you explicitly click the flash placeholder.

  • no more 'next page' style, please ;-( (Score:4, Informative)

    by TheGratefulNet ( 143330 ) on Saturday September 06, 2003 @06:14PM (#6889907)
    here ( http://www.anandtech.com/printarticle.html?i=1856 [anandtech.com]) is the printable (all continuous) version.

    causing hit counters to go up artificially just to see 'next page' drives me nuts!

  • If the AMD64 version of Windows XP 64-Bit is as stripped down as the current Intel version... then don't bother considering what performance would be like there anyway... check here for a list of things *NOT* included in XP 64-bit:

    http://www.microsoft.com/technet/treeview/defau l t. asp?url=/technet/prodtechnol/winxppro/reskit/prka_ fea_tfiu.asp

    But I guess we can do without features like Media Player, POSIX Compliance, Power Management, Windows Installer, and more... I guess..... just to have a 64-bit OS.

  • Will we have a library nightmare? (Score:3, Interesting)

    by r6144 ( 544027 ) <r6k&sohu,com> on Sunday September 07, 2003 @03:23AM (#6891877) Homepage Journal
    For optimal performance and compatibility, we need at least three sets of libraries: a pure 32-bit version (old apps have to run in 32-bit mode with a 64-bit kernel because the new instruction set is not entirely compatible with the old one), a "small" 64-bit version in which pointers are 32-bit in memory (so that most applications can get 64-bit and the extra registers, etc., without wasting memory on pointers), and a regular 64-bit version for the apps that really need the large address space. Seems that the nightmares of tiny/small/medium/large/huge/compact memory models in 16-bit x86 will come again.

    Anyway, those running other existing 64-bit CPUs should be able to give some advice.

Slashdot Top Deals

There is no opinion so absurd that some philosopher will not express it. -- Marcus Tullius Cicero, "Ad familiares"

Close