Slashdot Mirror

← Back to Stories (view on slashdot.org)

If I Had a Hammer

Posted by ryuzaki0 on from the 486DX-still-going-strong dept.

adpowers writes: "Anandtech is running an article about their preview of AMD's Hammer. They had one machine running 32-bit Windows and the other running 64-bit Linux. The Linux machine had a 32 bit program and an identical program that was compiled for 64-bit processor support. Both processors were less than 30 days old and running without any crashes, but they weren't at full speed." We did one Hammer story a day or two ago, but there have been several more posted since then (wild guess: the NDA expired). Tom's Hardware has a story, so does Gamespot.

3 of 141 comments (clear)

  1. They mention the need for plugin AMD compilers by Inthewire · · Score: 3, Insightful

    The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.
    Simple enough to say.

    I just wanted a lead-in for the following question:
    Did anyone else see a banner ad for Visual Studio .NET on Slashdot yesterday? Or was I hallucinating?

    --


    Writers imply. Readers infer.
    1. Re:They mention the need for plugin AMD compilers by Lurks · · Score: 3, Insightful
      The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.
      I took issue with the author writing that as well. Like it's some trivial task in software engineering to suddenly start writing a compiler which is comparable to what's out there already on the highly competitive x86 platform. (Codeplay does this already of course)

      Obviously this isn't what AMD need to do, they need to help people making compilers which support their platform. That's something I'd like to say of my company but it's hard enough work getting AMD to answer E-mail, let alone provide documentation and hardware samples of forthcoming CPUs. You'd think they'd care a bit more since we're the only people in the world making a compiler with vectorizes for 3D Now!, wouldn't you?

      By contrast, Intel give us virtually everything we could want in the world short of hard cash. Even though they have a department working on their own (highly competent) compiler, they recognise that wide support of their CPUs is a good thing and they should do everything to encourage it. AMD don't quite appear to have the same attitude at present although we live in hope.

      Also, AMD have kind of backed off their proprietary SIMD implementation (3D Now!) with their latest Athlon XPs. The 3D Now! Professional (as far as we can tell), is actually just the old 3D Now! but with SSE as well. An admission of defeat with regards to SIMD software support? One wonders what they're going to do with regards to double float and 128-bit integer SIMD, if anything (Hammer?). Support SSE2 and call it 3D Now! Advanced Server?

  2. Re:Two transition periods? by foobar104 · · Score: 5, Insightful

    Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.

    Actually, it is a very large number for disk arrays.

    I'm unaware of a filesystem that can scale as large as XFS; there may be others, though. XFS uses 64-bit addressing, allowing the filesystem to scale to 18 million terabytes (or 18 exabytes, if you prefer). No filesystem in the world has ever remotely approached that size. According to this nifty site, total worldwide disk drive production for the year 2000 only totalled 2.5 million terabytes. So to build a filesystem that's 18 million TB big, you'd have to commandeer all hard drive production, worldwide, for about 12 years.

    They estimate that the total amount of data stored on hard drives in the entire world is only about 4 million TB. That means you could theoretically put all the data in the world that is currently stored on hard drives-- all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem, and only use about 1/4 of the filesystem's capacity. Mount it under /earth and set the permissions to 700, please.

    Of course, this fact fails to address your basic premise, which seems to be that assigning unique integer addresses to every byte that a computer can access would be a reasonable thing to do.

    Even if there were a reason to do such a thing, don't forget that increasing your pointer size decreases your cache efficiency; you can fit twice as many 32-bit pointers in your cache as you can 64-bit pointers, which results in fewer cache misses and overall better performance. (How much better depends on how cache-friendly your task is in the first place, but 32-bit will never be less cache-friendly than 64-bit.)