Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
AMD

AMD Athlon 64 Performance Preview 188

k-hell writes "It seems like X-bit Labs have gotten their hands on an 'engineering sample of the AMD Athlon 64 2800+ processor'. Damage at Tech Report is writing that 'This is really fun, but I am a little concerned about their memory latency numbers.'"
This discussion has been archived. No new comments can be posted.

AMD Athlon 64 Performance Preview

Comments Filter:
  • by AndroidCat ( 229562 ) on Saturday April 19, 2003 @07:06PM (#5766470) Homepage
    When Athlon processors came out in 1999, the competition in the processor market became much worse.

    I don't think that word means what they think it does.

  • here's a mirror (Score:3, Informative)

    by linuxbaby ( 124641 ) on Saturday April 19, 2003 @07:14PM (#5766510)
    temporary mirror here [hostbaby.com]
  • by robbyjo ( 315601 ) on Saturday April 19, 2003 @07:15PM (#5766514) Homepage

    You should include the full quote of Damage, because just quoting out of context can be misleading. Here's the full paragraph (emphasis is mine):

    This is really fun, but I am a little concerned about their memory latency numbers. They haven't specified what units those numbers are in, but latency numbers come out of programs like cachemem in CPU cycles. Obviously, processors with higher clock speeds will see more clock cycles pass per second than processors with lower clock speeds. One must convert those numbers into comparable units, such as nanoseconds, in order to compare CPUs at different clock speeds. I do expect the Athlon 64 to have low memory access latencies because of its integrated memory controller, but I don't think the gap will be so great as the X-bit numbers would seem to indicate.

    So, the worry is about the units the latency numbers are expressed in. And when you'd see the numbers below, you get an idea why it is so:

    Athlon 64 2800+

    • Mem read speed: 2610.2 MB/s
    • Mem write speed: 1099 MB/s
    • Mem copy speed: 1541.7 MB/s
    • Latency: 96


    Athlon XP 1.6GHz

    • Mem read speed: 1747.8 MB/s
    • Mem write speed: 1156.9 MB/s
    • Mem copy speed: 1244.8 MB/s
    • Latency: 165


    Pentium 4 2.8C

    • Mem read speed: 3193.5 MB/s
    • Mem write speed: 1320.5 MB/s
    • Mem copy speed: 2678.6 MB/s
    • Latency: 260


    See it [xbitlabs.com] for yourself.

    • Those numbers sound about right to me. I would expect the integrated memory controller to reduce latency by quite a bit (~200% is not unreasonable). There is a lot of time lost in transfering data to the northbridge, then to DRAM.
    • by zenyu ( 248067 ) on Saturday April 19, 2003 @07:44PM (#5766630)
      Athlon 64 2800+ (true clock 1.6Ghz)
      latency: 96 cycles or 96/1.6 => 60 ns

      Pentium 4 2.8C
      latency: 260 cycles or 260/2.8 => 92 ns

      So there is a 33% improvement, which is cool. (i.e. the P4 is 50% slower)

      The SSE2 instructions were pretty much in equal to the P4 in throughput per cycle, that is as a SEE2 processor it performs like a 1.6Ghz P4... Hopefully they can push the clocks up as fast as Intel has with NetBurst.
      • He's assuming the numbers are in cycles though.
        Look down a bit further and you'll see times in ns for various memory sizes.

        WORST case is about 2.5 vs 4.3 or so (72% improvement) on the smallest size. The others are all close to or above a 100% improvement.
    • Inacurate.

      You also forget about bandwith. Here are some more benchmarks. [consumptionjunction.com]

    • Latency is in ns. I posted about similar benchmarks in xbitlabs' forums about 3 days before the article came out. Grrr and no credit for me :)
  • A number of other sites have gone ahead and linked it

    naw.. probably just slashdot
  • by bplipschitz ( 265300 ) on Saturday April 19, 2003 @07:19PM (#5766533)
    Did they burn their fingers?
  • by AndroidCat ( 229562 ) on Saturday April 19, 2003 @07:21PM (#5766541) Homepage
    On the picture of the chip, it's stamped "Copyright 2001".
  • by Anonymous Coward on Saturday April 19, 2003 @07:22PM (#5766543)
    The review of the Athlon 64 notes that the core frequency is actually less than that in the Athlon XP. The reason is that the wires are being loaded down with too many transistors, so the resistance-capacitance (RC) time constant is too high. I doubt that the AMD engineers are somehow less capable than the Intel engineers in designing transistor interconnects with low RC time constants.

    So, what could be the problem? The problem is that AMD is trying to support too many instruction sets. AMD should have axed 3DNow! and swallowed its pride. Supporting MMX, SSE, and SSE2 is sufficient.

    When you try to put everything and the chicken sink into a chip, you inevitably pay for it with a slower clock speed.

  • Does the high cache size of Sparc processors outweigh their slower clockspeeds? Do the instruction sets?

    I'll soon be getting a server that does involved calculations for for members of Math Addicts Anonymous [mathaddicts.org]. These will involve things like prime factorizations of insanely large numbers and calculating pi to more digits than anyone could ever care about. Assuming a budget of $500(the server will have other duties) for the motherboard/ram/processor, what would be the best architecture for the job?
    • At $500, you have just limited yourself to a mid-ranged Athlon or P4.
      • At $500, you have just limited yourself to a mid-ranged Athlon or P4.

        More like very high range. A quick glance at Pricewatch [pricewatch.com] will show you that currently, the fastest Intel, 3.06 ghz, costs $388. The fasted Athlon, the 3000+, costs $320. Even the 2.8 Xeon is $425.
    • I think the most important things for you are precision, FPU speed, and clockspeed. Here is what I think (but I'm just a hobbiest, this is not official end all opinion).
      • Pentium 4 - Wicked clockspeed, decent FPU, same precision as all x86 processors
      • Athlon - Fast clockspeed, great FPU, same precision as all x86s
      • Hammer - Fast clockspeed, great FPU, higher precision than x86s
      • PPC - Decent clockspeed, good FPU, don't know about percision

      That's all I know. If you can afford it I'd get a dual x86-64 box, put

    • For those two examples you probably want a fast integer unit, and cache isn't terribly important. For most math applications you want a cache as big as you can get it and a decent FPU, and then you worry about the clockspeeds. i.e. if you're multiplying two big matricies an old Sparc with 1M cache will kick the ass of a 3Ghz P4, if you can fit or almost fit in a 256k cache the P4 will win hands down. Umm, so you want a Athlon or P4, prolly an nforce2 motherboard with Athlon is the best performance/$ (get tw
  • My Observations (Score:4, Interesting)

    by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Saturday April 19, 2003 @07:27PM (#5766560) Homepage
    Well, first off I'll say that I agree that we need units on the memory latency. If they are in a unit of time (microseconds or something) then they really show what can be done with an onboard memory controller. But onto more "important" things.

    The processor doesn't take to many benchmarks, but you can't fault it too much. It's nice to see some numbers are the CPU in 32 bit mode, but let's not forget that EVERYTHING here is 32 bit (OS, programs, etc). I'd LOVE to see a comparison between 32 bit programs running under and identicle OS versions that do and don't support 64 bits (Win XP vs Win XP for x86-64 for example). I'd suspect that the performance would go up with a 64 bit OS (especially on the games, where drivers and such play such a big part). Considering it's clockspeed, it holds up very well. The fact that it's almost never far behind a current athlon with an identicle performance rating (which is actually like 400 mhz faster) shows that it can definatly run things well. This isn't the horridly crippled performance that we've all heard about with the Itanic.

    So what's my take on all of this? I think that this shows that the x86-64 can really become a success. I know some of you out there are thinking "Why would I buy one? I've got a 2.4 ghz Octium 7 and my PC is faster than that thing." That may be true, but many people aren't like you. My fastest computer is a PIII 933, so even at 1.6 ghz that Athlon64 can run circles around my best PC. If you are using a PC that's even a year or so old, you can probably benefit alot if you were to move up to an Athlon64 when it comes out.

    My notes on some specific benchmarks:

    • 3DMark 2k3 - The chip is only 4% behind the P4 despite the fact it's clocked at only about 60% of the P4. Impressive.
    • 3DMark 2k1 - The A64 is nearly identicle to the P4, despite the massive clock difference. And this is 32 bit code. Compiling a game for the x86-64 is supposed to increase performance up to 30%. Drooling yet?
    • UT2003 - The A64 is nearly 10% FASTER than the P4, despite the clock difference. "Office" benchmarks may not look impressive, but games are what counts ;)

    Now my objections to the benchmarking

    • Where is the 1.6 ghz P4 in this? They could underclock the P4, or just get a TRUE 1.6 ghz P4 so we can see how they compare clock for clock.
    • No 64 bit OS. I'd have liked to see them run Linux so they could do some tests to see how it performed with 32 bit code (UT2k3, Q3, etc) under a 64 bit OS. I understand that Windows isn't out yet so they couldn't use it.

    My final thoughts are this: it looks quite promising, and I can't wait to see more. More and more people with comeout with benchmarks as time goes on, and with the Opteron released now, we'll soon see benchmarks of it in SMP mode against other chips in both 32 and 64 bit OSes with 32 and 64 bit code. Either way, it looks like it's more successful than the Itanic.

    • Re:My Observations (Score:1, Insightful)

      by CTho9305 ( 264265 )
      Could you explain WHY it is relevant how a 1.6GHz P4 performs? What matters is that while the Athlon64 only currently clocks up to 1.6 GHz, the P4 clocks at 3.0ghz. If you want to make an argument about power usage scaling with clock speed, you still have to compare the watts/MHz of the processor, while considering the instructions per clock and clock speed.

      Also, you have to consider that by the time there is a lot of 64-bit code in use, there will probably be significantly more advanced processors avail
    • If you look a bit further down on page 6 you can see latency times in nanoseconds. It's about a 100% improvement in all cases (of memory sizes) but one (where it's 70%)
    • Agreed, this is prety impressive, especialy since the Athlon 64 didn't have all 16 registers that it uses in 64-bit mode available - Like you said the extra registers can increase perfomance up to 30%. And in 64-bit mode it doesn't use any of the x87-register-stack brain damage. I can't wait to get my hands on one of these!
    • by aeoo ( 568706 ) on Saturday April 19, 2003 @08:29PM (#5766807) Journal
      Where is the 1.6 ghz P4 in this?

      That's irrelevant. The proper way to square off chips is based on money. In other words a $200 dollar chip should go head to head with another $200 dollar chip, and an $800 chip goes against another $800 chip.

      That's the only way to get fair results that are independant of implementation details. Clock rate the chip runs at is an implementation detail. It's not important. What's important is WORK per DOLLAR. That's the only thing that matters. Period.
      • Well, I will have to disagree. AMD has to sell their CPUs at an lower price to induce people to buy, so they absolutely have to have a price/performance advantage.

        I'm also able to leverage that further: by running Gentoo Linux, you can optimize for your CPU architecture, which helps the Athlon, as any SW out there is focused for the P4

        Not that I'm complaining, as the last Intel processor I bought was a Celeron 400MHz. I've gone Athlon and haven't looked back.

      • That's irrelevant. The proper way to square off chips is based on money. In other words a $200 dollar chip should go head to head with another $200 dollar chip, and an $800 chip goes against another $800 chip.

        Or, if you're hard-core, you would compare the best possible chip you can get from one manufacturer against the best possible chip you can get from another.
      • From a technical interest point of view, it can be most interesting to compare with another chip of the same clock speed, because then you can see things like how much work gets done per clock cycle.

        It's more important for reviews to focus on the advantages and disadvantages of a whole family of chips rather than on one particular model clocked at one particular speed. This is particularly important when the product hasn't even been released yet. A chip family like the Pentium 4 or the Althon 64 may last
      • I agree that performance per $$ is the only interesting benchmark but the thing is: Athlon64 are not sold at the moment!

        So in the meantime, benchmarks which show the performance per clock of the Athlon64 have their place..
      • The problem with work per dollar is that prices are cut with 40% anyday.. so a price comparison is not valid for a long time. But, they sure as hell are important when it comes to placing an order for 200 machines..

        So what matters is: work per time and then you can calculate costs later....
      • They always price their chips heaps lower.

        To the point that an AMD chip can sometimes be cheaper by 3 figures over a Intel chip of the same performance (that's performance, not bus speed).

        Gez I remember when Duron 600s were heaps cheaper than the P6 Celeron 600 (Cu'mine), even though they trounced 'em performance wise. & still outperformed them even when one plays arround with the Celeron's bus speed & then unlocked the Duron & played arround with its bus speed & multipler, so that both ch
    • This isn't the horridly crippled performance that we've all heard about with the Itanic.

      Uh, the Itanium 2 processor at 1GHz performs about as well as a 2.5GHz P4. Even better at FP ops, close to 2.8GHz.
    • Re:My Observations (Score:3, Informative)

      by captaineo ( 87164 )
      No, performance in general would go *down* if you simply re-compiled existing code from 32 to 64 bits. (this is because pointers would double in size, and executables would grow slightly, increasing the cache footprint).

      The only ways to gain performance moving to 64 bits are:

      1) re-write software that needs a >4GB working set (e.g. databases) to use 64-bit pointers rather than paged or segmented 32-bit addressing

      2) re-write high-performance integer code to process values in wider chunks (although you c
      • If the code size change is noticable I worry for your code.

        There won't be a cache difference either, the 64bit chips are word aligned to 64bits. They are optimized for that.

        Generally no differnece at all between 64 and 32bit processors, as demonstrated by sparc and POWER/PowerPC.

      • Re:My Observations (Score:3, Insightful)

        by SEE ( 7681 )
        True in general, but there's one more factor -- the x86-64 instruction set has more registers than x86-32.
      • Actually, the great part is the extra registers. That, along with the integrated memory controller and the improved branch prediction should help make it significantly faster than the Athlon XP, even in 32-bit code (it requires recompilation but no rewriting). The bigger cache is also nice, but I suspect most Athlon 64 models will have 512 KB L2, like the Barton XP.

        64-bit registers and bigger-than-32-bit addressing (40-bit for now, I think, with higher models using 48-bit) are there mainly to give AMD a fo
      • For x86-64 the code size apparently stays about the same, because the additional registers reduce the need for register-memory transfer instructions. Data structures with pointers will all grow, though.
  • 'This is really fun, but I am a little concerned about their memory latency numbers.'
    Note, this is not because they're bad numbers, but rather because the units aren't specified, and may be clock cycles, which wouldn't be a fair comparison to the other processors.
  • tested with windows (Score:3, Interesting)

    by paradesign ( 561561 ) on Saturday April 19, 2003 @07:31PM (#5766571) Homepage
    in 32 bit mode... wtf?

    couldnt they have used any one of the 64bit linuxes? this sounds like a bs review to me;

    • Exactly. I think this benchmark is worthless. Tested with Windows XP? That's about as good as racing a Geo Metro vs. a drag racer in the quarter mile.
      • You're right. They shouldn't test in the environment that will likely be predominately used. They should boot into some micro-OS/benchmark suite because that's what we'll all be doing when we buy the CPUs.
    • Maybe for the Opteron "server" chip that would be relevant, but this is the "consumer" version. They rightly tested it with the software that will be most-often used by potential customers.
    • by atam ( 115117 ) on Saturday April 19, 2003 @08:19PM (#5766778)
      Why not? One of the supposed selling point for the Athlon 64 is that it will run 32-bit software equally well (unlike the Itanic). Also, at its introduction, there will not be that many 64-bit software available. Hence, it is important to look at its 32-bit performance so that you could decide whether to get it early (if the 32-but performance is good) or wait until more 64-bit software is available (if 32-bit performance is worse than current Athlon XP).
    • The chip tested was a consumer version of the athlon64 (one memory channel). If it cannot run 32 bit code with any reasonable amount of speed (i.e, faster than AXP and comparable to latest p4's), then the chip is destined for failure.

      Good news is that it seems like it can.
  • by Kewjoe ( 307612 )
    X-Bit was down all morning... I had assumed it was being slashdotted... only to find out the link was just posted.

    If non-Slashdotted traffic can bring down their site.. god help them now.
    • No kidding. Maybe if they can get their hands on enough of these new AMD chips they can build a system capable of withstanding the load.
    • what, they going to go do more?

      thats like watching someone gett hit with a 1 ton block of lead, then hit with a 20 ton block of lead, dead is dead.
  • Single page view (Score:4, Informative)

    by TeknoHog ( 164938 ) on Saturday April 19, 2003 @07:43PM (#5766622) Homepage Journal
    Printable version here [xbitlabs.com].
  • Umm.... (Score:5, Funny)

    by LucidityZero ( 602202 ) <sometimesitsalex ... m ['gma' in gap]> on Saturday April 19, 2003 @07:48PM (#5766642) Homepage
    From the article:
    Unfortunately, 64bit operation systems and applications are not available yet.
    Really? I could have sworn...
  • by herrd0kt0r ( 585718 ) on Saturday April 19, 2003 @07:52PM (#5766670)
    lemme sum up the article:
    - WAHOO! CHECK dis shit OUT! we got an athlon 64 chipz0rz!
    - it's beefcake, dood. memory controller insIIIIDE!
    - we're just gonna test it with 32 bit shizzle.
    - it's like, good at some things, not so good at others.

    anyway, here's something to consider: the sample they tested is 2800+ per AMD's performance rating spec, and it runs at 1.6gHz. yeah. most of the tests and graphs n stuff show it running around the level of a P4@2.53gHz. alright, so it doesn't exactly match the P4@2.8gHz. but think about this:

    it's running at 1.6gHz!

    nevermind the fact that it doesn't squash the fastest P4 they tested it against into the ground. it's just amusing to see how good the architecture is of the A64. i dunno. i think it's pretty cool, anyway.

    anyway, seriously speaking: what use is testing a processor touted as being a 32-bit compatible 64-bit chip, when _NO_ 64 bit apps were used in testing?!

    "uh. well. it ran the 32 bit stuff fine. and uh. it didn't fry."
    • Well the important thing here is how fast they can ramp up the CPU speed. If they can get it up to 3 3.5 GHz it will undoubtedly be a monster at those speeds, but as we all know, there are some operations where architecture can't replace raw GHz.

      I also understand that the pipeline is a bit longer so I wonder if this decreases the IPC of the chip in comparison to the AXP or whether the other enhancements like the memory controller and HT link make up for that.
      • true enough. i agree with you wholedheartedly. if it performs as well as a p4 running at 2.5-2.8gHz, then it should totally demolish the competition when its clock speed is bumped up.

        but my concern is that there are a lot of factors that go into dictating the clock speed limitations of the chip. i mean-- the latest 32-bit athlons run pretty darn well compared to P4s, considering their clock speeds. but one gets the feeling that they're reaching the upper strata of how high they can be ramped up.

        i think so
      • The other enhancements to the chip more than make up for it. In fact, it should typically perform anywhere from 5-25% faster than an equally clocked AthlonXP.

        The big downside to a longer pipeline is that it increase the performance penalty of flushing the pipeline after a mispredicted branch. However, AMD did two things here. First the Athlon64 has a better branch predictor than the AthlonXP, which should reduce the number of mispredicted branches. The second thing that AMD did was to change the pipeli
    • by Anonymous Coward
      think about this:
      it's running at 1.6gHz!


      And what is your point exactly ?
      Take an Itanium2 at 1Ghz [*] and it will beat that 1.6 GHz processor to the ground. So are you going to sing the praise of the Itanium2 now ? No ? Ah sure it doesn't come from AMD but from Intel (and HP), so surely it must be a marketing trick.

      You are a moron.

      [*] soon to be replaced by a 1.5Ghz version
      • And what is your point exactly ?
        Take an Itanium2 at 1Ghz [*] and it will beat that 1.6 GHz processor to the ground. So are you going to sing the praise of the Itanium2 now ? No ? Ah sure it doesn't come from AMD but from Intel (and HP), so surely it must be a marketing trick.
        You are a moron.


        yes, i will sing the holiest of holy praises for the i2 . it's nifty that it can perform so well at a lower clock speed . yes . and no .

        and finally,
        You are presumptious. [*]

        [*] your space bar seems to be malfun
    • >it's running at 1.6gHz!

      Maybe they should have got their hands on one of those Liquid Nitrogen cooling units (or whatever) and just overclocked the hell out of it, see just how fast this bad boy will really go ...

      I mean if you are going to dream, dream BIG.
    • incase AMD's push for x86-64 falls through and they're stuck with supporting 32bit for a few more decades.
    • >anyway, seriously speaking: what use is testing a processor touted as being a 32-bit compatible 64-bit chip, when _NO_ 64 bit apps were used in testing?!

      Maybe because the majority of people who will be buying it will be running a 32bit Operating System, with 32 bit applications.

      Unless you think Microsoft is gonna release a 64 bit XP Home anytime soon.

      The Athlon64 is a successor to the Athlon XP, not an alternative, so it has to run 32 bit code as fast or faster than an XP, or no one will touch it.
      Tho
  • by WoTG ( 610710 ) on Saturday April 19, 2003 @07:53PM (#5766672) Homepage Journal
    Remember that this "preview" probably violates one or more NDA's, and it is of a desktop x86-64 chip that is scheduled for September release. In the meantime, it's bigger brother, the Opteron, who has more memory bandwidth, (usually) more cache, and multiple processor support will be released in less than a week (Tuesday to be exact).

    Now the reviews that out in 4 days time should be much more interesting reads. I expect to see someone do a solid x86-32 vs. x86-64 comparison using Linux, maybe other OS's too. And yes, probably even Quake frame rate results. =)
  • This would create a bottleneck and make AMD look bad. Was there a chipset bug maybe?

    • The memory was not crippled. The concern is that the latency numbers on the A64 are too GOOD. Apparently the units of measurement are important in calculating things like this and might need some extra tweaking to account for discrepencies in clock speed.
  • by OoSync ( 444928 ) <`wellsed' `at' `gmail.com'> on Saturday April 19, 2003 @08:05PM (#5766728)
    To add more fuel to the "its only an engineering sample", check out the date on the
    [xbitlabs.com]
    processor itself.

    Imagine, with nearly two years of time to improve on this piece of silicon just what is in store for the Clawhammer. Personally, i'm waiting for it so I can finally upgrade my Athlon 600.
    • Copyright date != date of manufacture... mkay?
    • While this is 110% pure speculation, there are other numbers on the CPU. The one that I'm looking at is 0301 (2nd line of numbers/letters) which I will guess to be 1st week 2003. However, since this is pure speculation, and they got their hands on it *somehow* it could just as easily be 3rd week 2001.

      OK, so that doesn't clear up anything. :-)
      • by rabidcow ( 209019 ) on Saturday April 19, 2003 @11:06PM (#5767361) Homepage
        The one that I'm looking at is 0301 (2nd line of numbers/letters) which I will guess to be 1st week 2003.

        Exactly, date codes on chips, which tell you the date of manufacture, are usually 4 digits: two digits for the year, then two digits for the week in that year.

        If you RTFA (as opposed to just looking at the pretty pictures), they say, right under that image: "The production date in the next line of the marking indicates the beginning of this year."

        This is pretty standard, I can pull out my old 8088 MB and read the date code off the processor: 8937 (1989, 37th week) You can find similar date codes on most chips and PCBs. (eg, that 8088 MB has 8945 printed on the back)
  • very old rev (Score:4, Interesting)

    by Anonymous Coward on Saturday April 19, 2003 @08:05PM (#5766729)
    Being that I am an AMD employee, I know for a fact that B0 (the version of clawhammer that they are benchmarking) is a very early rev, and should not even be considered when thinking about final benchmarks. Geez.

    Well, one thing is for sure, xbit labs just blew their chances of ever getting their hands on another upcoming bleeding edge technology again.
    • If you're right, that it is an older chip, then I'm very excited for Clawhammer. Granted, AMD could totally screw the pooch and botch the final CPU, or VIA could fuck up the only viable chipset, or what have you, but this does make me very excited.

      It's a 64 Bit processor that doesn't perform like a dog in 32bit mode. I want to see 64 bit performance numbers.

      If the 64Bit mode performance numbers are decent, and if the 32Bit mode performance numbers are decent, then AMD could have a huge hit on thier hand
  • by vlad_petric ( 94134 ) on Saturday April 19, 2003 @09:50PM (#5767098) Homepage
    The tests are pretty much showing that an Athlon-64 does not outperform a 32 bit Athlon when running 32 bit apps.

    But here's another way to look at it - Itanium also has an x86 layer, but because it's really just an emulation, its performance sucks.

    So I view this as a huge success. Why ? Because an Athlon-64 will be able to run "legacy" 32 apps at the same speed, while 64 apps will run faster.

    You'd probably wonder why this is the case. Well, IMNSHO it's not because of the wider registers/ALUs, etc, but because of other improvements to the Instruction Set Architecture, like the 8 extra registers (16 total). Because you only have 8 registers on a regular x86, compilers can register-allocate very little. Adding 8 more registers means that you can keep more stuff in the register file, and you don't have to go to the stack (data cache) every single time.

  • Another factor to consider is that the chipset is a critical factor: it took the Athlon almost 2 years before there was a solid chipset for it. Hopefully, AMD is already working on this.
  • UT2003... (Score:2, Interesting)

    by Nameles ( 122260 )
    Wasn't that designed with 64-bit processors in mind?

    Now this doesn't make much sense, because how can you run that in 64-bit mode even though you have a 64-bit processor, when the OS is running in 32-bit mode?

    Or am I dreaming?
  • Surely the real point of a 64 bit chip is its 64 bitness, not a pissing match with chips crippled with limited memory addressing.

    It holds is own with 32bit chips, but the real benefit of this is when its used in an environment where more than 4GB of memory is an important parameter. Those other competitive chips won't stand a chance.

    On my web site (under building PCs) I have some rather old data about ENTRY level machines and predictions of where these will be in the future. It looks as though we are get
    • For the masses, 64-bit is a marketing gimmick. It's useless and will continue to be useless for several months (programs need rewriting, retesting, etc., assuming the authors bother to do it in the first place). This is for the 64-bit registers.

      The 64-bit memory controller (which doesn't actually support 64-bit addressing, BTW) is even less relevant for normal users. Most people don't have any use for more than 512 MB. Even workstations can work perfectly with 2 GB or so (unless you're working with floatin

  • Classic hardware review article. Take every bit of old-news, re-hashed, "everyone's seen it before" information you can find to pad out your 2-page article to at least 10 pages. Insert lots of huge pictures to pad it out even further. After all, you get paid by the banner impression, right?

  • The memory controller in the chip they tested handily beat out the dual-channel Nforce platform, and while it didn't beat the dual-channel DDR 400 memory of the P4, it wasn't too far behind.

    Here's the cool part: That was an Athlon64. A desktop-oriented chip with a single-channel memory controller. The chips that are coming out on Tuesday are the "Hammer" multi-processing chips, targetted at servers, with *dual-channel* memory interfaces. Look at the memory numbers on the single-channel, and co
    • Plus of course, they ran WinXP on it, so they tested it in 32bit mode. Its concievable it might be faster still in long mode.
  • In an interesting review they would have managed to work out how to use Linux and run some 64 bit apps instead of "Look mom, I can run Windoze, I'm so 1337, and look, I can download some 32 bit benchmarks and take screenshots too!"
  • Euhm, to the poster: low latency is better than high latency. It is an indication for the time you have to wait before the first bit of data is available. The P4 has a faster memory throughput, but higher latency. This means you'll have to wait longer for the data to become available, but once it's there, you'll get it faster.

No line available at 300 baud.

Working...