AMD SEMPRON CPU

Discussion in 'PC Hardware' started by patrick, Jul 29, 2004.

  1. patrick

    patrick Guest

    There have been some questions about whether we should start building 64
    bit systems. There is nothing that is true 64 bit clean (with NO 32bit
    code embedded) from Microsoft.

    Linux offers quite a bit of 64bit, clean, stuff, (with the source
    code!), and always has, with lots more coming...
    Here is a synopsis of 64 bit technology, from a published, and
    respected, engineer.

    "AMD is starting to phase out it's Duron and Athlon XP processors.
    In it's place, it has an interesting strategy ... Sempron.

    - What's in a name? Nothing actually.

    First off Sempron is a name, not a processor design.
    In fact, different Semprons are different processor cores.

    Socket-462 Semprons are based on the 256KB "Thoroughbred-B" (32-bit
    Athlon XP).

    Socket-754 Semprons are based on the 512KB "Newcastle" (64-bit Athlon
    64) with half the cache disabled along with the x86-64 ISA.

    Socket-939 Semprons are planned in the near future.

    - So what is Sempron? The new Duron.

    Sempron is the new Duron, but it spans both AMD's old 32-bit and new
    64-bit platforms. It uses the relevant core for each.

    On the legacy Socket-462 side, it completely replaces the Duron and
    Athlon XP, which will no longer be produced next year.

    On the newer Socket-754, it is a low-cost alternative more expensive,
    full Athlon 64 Socket-754 processors. The 64-bit x86-64 instructions
    are lost, but it gains the advantages of the segmented memory and
    HyperTransport busses.

    And in the near future, there will be the Socket-939 Sempron. Again,
    gone is the 64-bit instructions, but it gains having two (2) memory
    channels separate from the HyperTransport bus.

    If anything, as AMD releases newer CPUs and vendors release newer
    mainboards with DDR2 support or faster HyperTransport interconnects for
    I/O, Sempron can run on earlier generation systems with slower DDR
    channels and the older HyperTransport interconnect speeds.

    - No 64-bit? What's that mean to me? Depends on the OS.

    If you run Windows, 64-bit doesn't buy you anything. In fact, it can be
    slower as XP 64-bit Edition runs the CPU is in "Long" 64-bit mode, but
    the applications are still 32-bit with 32-bit libraries. Make no
    mistake, XP 64-bit Edition is heavily 32-bit and that's unlikely to
    change for compatibility. The reviews on AnandTech's site show how
    little difference there is in XP v. XP 64-bit.

    So Sempron v. Athlon 64 is really just a matter of cache size.

    But if you run Linux, nearly all libraries and software shipped in a
    Linux/x86-64 distro are 64-bit (with a few, common 32-bit libraries).
    With source code and the 64-bit "clean" GNU Toolchain which almost
    everything is written to, this is easy for the entire Linux world to
    do. The performance difference is staggering as shown on AnandTech's
    site of Linux/x86 v. Linux/x86-64.

    So Sempron v. Athlon 64 now becomes a 64-bit performance consideration.

    - So what should you buy? Depends.

    For maximum performance, it's no so much the CPU, but the Socket.

    Socket-939 sports (2) DDR400 channels segmented from (1) 2000MT
    HyperTransport channel. The total aggregate throughput is up to
    2*3.2GBps+8.0GBps = 14.4GBps (DDR400).

    Socket-754 sports (1) DDR400 channel segmented from (1) 1600MT
    HyperTransport. The total aggregate throughput is up to 3.2GBps+6.4GBps
    = 9.6GBps.

    Socket-462 is the legacy "front-side bus" (shared memory-CPU-I/O)
    approach upto DDR400. The total aggregate throughput is up to 3.2GBps.

    In the case of Windows, which is really 32-bit even if you run XP 64-bit
    Edition, Sempron is really just a cache size issue versus Athlon XP/64
    (and socket) and nothing else as far as the CPU itself. So the only
    other difference is the total aggregate throughput of the Socket as
    above.

    In the case of Linux, which is true 64-bit in Linux/x86-64, Sempron now
    becomes a performance hit versus Athlon 64 (64-bit, Socket-939/754),
    although relatively unchanged versus Athlon XP (32-bit, Socket-462), in
    addition to the cache size and total aggregate throughput.

    - Socket-754 Sempron v. Socket-939 Sempron

    According to the AnandTech review, the $120 Socket-754 Sempron 3100+
    performs around the same as the $140 Socket-754 Athlon 64 2800+ in
    32-bit Windows. It doesn't save you much, so it's a toss up for
    Windows. But for Linux, you probably want to splurge the extra $20.

    In reality, the Socket-939 with its two (2) DDR channels and slightly
    faster HyperTransport is the real winner for _any_ OS, especially
    workstations that throw a lot of data around (or servers for that
    matter, although you'll want more I/O options, which is another story
    ..

    But you'll pay for it as Socket-939 Athlon 64/FX processors or more
    costly than their Socket-754 bretheren. But soon there will be a
    Socket-939 Sempron, which brings us back to what OS you will run? If
    you run Windows, then Socket-939 Sempron might be "the cheap bomb," but
    for Linux, Socket-939 is probably worth going with even the lowest end
    Socket-939 Athlon 64.

    - SIDE STORY: Issues with 64-bit libraries and 32-bit applications

    One of the main reasons Microsoft doesn't want to tackle a true XP
    64-bit is because of the support issues. First off, their entire
    toolbase is not 64-bit "clean." Complicating this is the fact that when
    the AMD x86-64 is in "Long" mode, you cannot have 32-bit applications
    calling 64-bit libraries -- at least not without the library being
    modified.

    The GNU Toolchain (Linux is a GNU system, and many other UNIX systems
    are GNU compatible these days) has been 64-bit "clean" since the
    mid-'90s. If the source code is available, the program can typically be
    recompiled for 64-bit, and use the 64-bit libraries, without issue. In
    other words, there's probably a 64-bit version out there that is easy to
    find, or can be built easily for Linux/x86-64 (without all that techie
    stuff .

    You see, in Linux, most programs are written by developers to use GNU
    Autoconf. Using GNU Autoconf means it's not only "portable" to 64-bit,
    but even non-PC platforms. If GNU Autoconf detects /[usr/]lib64, it
    will attempt to build against it and create a Linux/x86-64 "target"
    (i.e., a true 64-bit version of the program using those 64-bit
    libraries). In other words, if you use an RPM distro, you build the
    binary version of programs from the same Source RPM (.src.rpm) file,
    with the same _single_ command (e.g., "rpmbuild -bb program.src.rpm") as
    for 32-bit x86 (or any non-PC architecture for that matter).

    That usually takes care of it, 0 issues.

    In the rare case of a Linux application (typically a binary one without
    source code -- like a commercial program) requiring 32-bit libraries,
    the Linux/x86-64 distro may already include them. Applications that
    use Linux/x86-64 libraries link to those in /[usr/]lib64, and those that
    don't link to /[usr/]lib, the latter being the same as 32-bit x86. If
    the distro doesn't include the 32-bit version required for an
    application, automatic fetching and dependency checking becomes easy
    with APT/YUM commonly used by modern Debian or Red Hat platforms (among
    others).

    In other words, a Red Hat Linux/x86-64 system (Fedora Core x86-64 or
    even Red Hat Enterprise Linux WS/AS x86-64) could fetch the 32-bit
    libraries from the 32-bit Fedora Core/Extras repositories via its normal
    method with APT or YUM. The process is very transparent altogether to
    the user. Likewise, in the case where source code _is_ available, APT
    or YUM could be used to fetch the source RPM (.src.rpm) and attempt to
    build and install it against /[usr/]lib64.

    Source code is so rare in the Windows world, and the Microsoft Toolchain
    is not 64-bit "clean" except for some core components, it's virtually
    impossible for Microsoft to do the same. Hence why XP 64-bit is still
    heavily 32-bit. So even though AMD x86-64 is x86 compatible, there is
    still the issue of 32-bit programs being unable to use 64-bit libraries,
    even if the 64-bit "kernel" of the OS can run 32-bit programs.

    Confused yet? Don't worry about it, the Linux/x86-64 distros hide the
    majority of this from you. I just talk about it for completeness.


    -- Discussing distributions is like discussing political parties. Not
    only do they enflame people, but they often break down into sets of
    blind assumptions. Instead, people should focus on the specific details
    of underlying technologies, just like one should when it comes to
    specific terms in legislation. Because the similarities are often more
    surprising than the differences.
    ---------------------------------------------------------------- Bryan
    J. Smith, E.I.
    _______________________________________________ PC_Support mailing list

    http://www.matrixlist.com/mailman/listinfo/pc_support"
     
    patrick, Jul 29, 2004
    #1
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.