AMD SEMPRON CPU

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"