Slashdot Mirror


64-bit Computing: Looking Forward to 2002

msolnik writes: "Over at RealWorldTech they've published an article on the future of 64-bit performance. This article covers the different technology from Sparc to Hammer. Its a great read if you are looking for information on up-and-coming products from Intel, AMD, Sun, and Compaq."

8 of 233 comments (clear)

  1. AMD's gonna win by Anonymous Coward · · Score: 3, Insightful
    Intel's 64-bit CPU doesn't work, Compaq sold out and Sun is pricing itself out.

    AMD is the future. Glad to see an underdog win.

    1. Re:AMD's gonna win by spiro_killglance · · Score: 5, Insightful
      AMDs going for a slightly different track, AMD
      is the only one trying to put 64-bit on the
      desktop. Now for us linux freaks SUSE Linux
      and NetBSB will be fine for a 64-bit desktop,
      but if AMD want to lock up some of the market
      into x86-64, they really need a mainstream OS.
      Unfortainately that means Windows, and "if
      we build it they will come" doesn't necessary
      work if they is no competition. Still in the
      mean time, Crawhammer will be a damn fine 32-bit
      chip as well, and Sledgehammer will bring
      high-end servers right down to mid range prices.

  2. Intel learning from their mistakes by jazzyjez · · Score: 5, Insightful

    Much as I hate to say it, the Intel McKinley looks like a very well designed piece of kit, and it appears Intel have learned from their mistakes with the P4 by including a big, fast 3-level cache on the McKinley. It's also good to see them reducing their pipeline size, which means it may finally be able to compete with the G4 in terms of efficiency. However, this is of course going to kick them in the teeth in terms of competing on processor speed, which they have been pushing so hard recently in their marketing.

    The same can't be said of AMD's offering, although in fairness the Hammer is not directed at the server market unlike the McKinley. The pipeline is longer than both their previous design and the McKinley, which is going to give them a performance hit. We can only hope that their cache is as good as Intel's.

    What amazes me is that they can still keep adding instruction extensions without too much of a performance hit. Anyone looked at the latest instruction set documentation for these processors? Eugh! The pain of backwards compatibility...

  3. AMD is deceiving you by hatchet · · Score: 3, Insightful

    First of all I'd like to say, I am not biased in either way.. after all I'm going to get me a new AthlonXP next week.
    IA64 is very different from x86-64. AMD's 64bit solution is nothing more than extension to current 32bit instruction set. Of course there are some tweaks, but nothing very radical. You will still be able to run old 16 and 8bit code efficiently.
    Intel's IA64 is a huge step in the future... architecture wise is far superior to x86-64. Why?
    Why do we need 64bit processors? Addressing? Nah, current processors can address enough space.. with 386 processors FAR addressing was introduced, which expanded allocatable address space drastically. (those silly DS, SS, .. registers) And newest processors can deal with them with same ease as with non-far addressing.
    AMD's 64bit solution currently has no real value.. except for huge data storage (could work faster with 64bit data blocks) and probably some heavy encryption. x86-64 compiled Quake3 would make minimum use of 64bit registers.. and would probably be just a margin faster than IA32 compiled version.
    Is IA64 better? Yes it is. IA64 has 128 usable 64bit registers, predicates... But that is not all.. in single 64bit register you can store 4 16bit values(common integer). (or 8 8bit or 2 32bit)And manipulate with them almost as much as you like. And if you have 4 integers in other register.. you can make 4 arithmetical operations with SINGLE instruction. You can do similar things with floating point operations... and with ILP you could do 3 instructions per cycle. This means that Quake2's VectorAdd/Subtract could be done in SINGLE cycle.
    Clawhammer will be better for a year or so.. but soon it will hit the ceiling. Intel will be able to get better performance from 1/2 clocked IA64.

    And please don't respond with lame comments if you haven't read at least whitepapers from Intel and AMD.

    1. Re:AMD is deceiving you by SurfsUp · · Score: 4, Insightful

      You don't have a clue. Let me just pick out a couple of the grossly wrong items...

      Why do we need 64bit processors? Addressing? Nah, current processors can address enough space.. with 386 processors FAR addressing was introduced, which expanded allocatable address space drastically. (those silly DS, SS, .. registers) And newest processors can deal with them with same ease as with non-far addressing.

      Sheesh, where are you coming from? You can address 64 Gig of physical memory with an x86 now, but you can only address 4 Gig (at most!) of it linearly. 32 bit address registers, get it? Gosh, and far addressing was introduced with 386's was it? Give me a break, try 8086's.

      AMD's 64bit solution currently has no real value.. except for huge data storage (could work faster with 64bit data blocks) and probably some heavy encryption. x86-64 compiled Quake3 would make minimum use of 64bit registers.. and would probably be just a margin faster than IA32 compiled version.

      Right, and I'm supposed to believe you on this, given your performance above. Um, you seem to have ignored the value of being able to crunch 8 byte integers, or pixels 8 bytes at a time, nicely matching the width of the MMX registers. For starters. Repeat this to yourself: "sledge hammer". "sledge hammer". Good, that's more like it.

      Is IA64 better? Yes it is. IA64 has 128 usable 64bit registers, predicates... But that is not all.. in single 64bit register you can store 4 16bit values(common integer). (or 8 8bit or 2 32bit)

      Um, and guess how many 16 bit values you can store in a 64 bit sledgehammer register? Ah, and guess how many fp/mms instructions sledge can retire per cycle?

      Clawhammer will be better for a year or so.. but soon it will hit the ceiling. Intel will be able to get better performance from 1/2 clocked IA64.

      You don't have any idea why it's called itanic, do you. Moderaters, take a look above. Remember, that's what 'random' looks like. Yes, I've got mod points right now. No, I won't waste them on you.

      --
      Life's a bitch but somebody's gotta do it.
  4. Re:64-bit is more than speed by BCoates · · Score: 3, Insightful

    Huh? you could do 32 bit addressing long before you could buy 4GB drives, but nobody thought memory mapping your hard drive into your address space was a good idea then... What would be the point?

    --
    Benjamin Coates

  5. Re:So why do I need 64bits? by thogard · · Score: 3, Insightful

    Since that was marked troll, I'll blow more karma...

    With most operations, 64 bits isn't 2x as fast its 1x as fast unless you deal with the stack in which case it could be even slower.

    Addressing has little to do with word size. The 8088 shows that.

    Suns running in 64 bit mode are offten slower than running in 32 bit mode.

    Nintendo 64 games are all 32 bit code with just a few 64 bit operations. The good emulator proved that.

    As far as going two 32 bit ops at once, I still don't need a 64 bit data path to do that, I just need several 32 bit data paths. What I don't need is to dump a bunch of unused 64 bit number on the stack everytime an exception happens (which one of my computers has done about 1047563950 times in the last 51 days)

  6. FAR addressing. by leuk_he · · Score: 3, Insightful

    Why do we need 64bit processors? Addressing? Nah, current processors can address enough space.. with 386 processors FAR addressing was introduced, which expanded allocatable address space drastically.

    Far adressing can handle 4GB. but 4GB is not much by today standards(it is not little either). You want flat adress space, and ram is cheap this days. 32 bits get you to 4GB, if you want more you have to resort to tricks. (those silly DS.DD etc)

    With the first 64 bit alpha's they used this as an argument: it is useful for fast memory scans when using big databases.

    --640 Kb will be enough....