There have been some questions about whether we should start building 64\nbit systems. There is nothing that is true 64 bit clean (with NO 32bit\ncode embedded) from Microsoft.\n\nLinux offers quite a bit of 64bit, clean, stuff, (with the source\ncode!), and always has, with lots more coming...\nHere is a synopsis of 64 bit technology, from a published, and\nrespected, engineer.\n\n"AMD is starting to phase out it's Duron and Athlon XP processors.\nIn it's place, it has an interesting strategy ... Sempron.\n\n- What's in a name? Nothing actually.\n\nFirst off Sempron is a name, not a processor design.\nIn fact, different Semprons are different processor cores.\n\nSocket-462 Semprons are based on the 256KB "Thoroughbred-B" (32-bit\nAthlon XP).\n\nSocket-754 Semprons are based on the 512KB "Newcastle" (64-bit Athlon\n64) with half the cache disabled along with the x86-64 ISA.\n\nSocket-939 Semprons are planned in the near future.\n\n- So what is Sempron? The new Duron.\n\nSempron is the new Duron, but it spans both AMD's old 32-bit and new\n64-bit platforms. It uses the relevant core for each.\n\nOn the legacy Socket-462 side, it completely replaces the Duron and\nAthlon XP, which will no longer be produced next year.\n\nOn the newer Socket-754, it is a low-cost alternative more expensive,\nfull Athlon 64 Socket-754 processors. The 64-bit x86-64 instructions\nare lost, but it gains the advantages of the segmented memory and\nHyperTransport busses.\n\nAnd in the near future, there will be the Socket-939 Sempron. Again,\ngone is the 64-bit instructions, but it gains having two (2) memory\nchannels separate from the HyperTransport bus.\n\nIf anything, as AMD releases newer CPUs and vendors release newer\nmainboards with DDR2 support or faster HyperTransport interconnects for\nI/O, Sempron can run on earlier generation systems with slower DDR\nchannels and the older HyperTransport interconnect speeds.\n\n- No 64-bit? What's that mean to me? Depends on the OS.\n\nIf you run Windows, 64-bit doesn't buy you anything. In fact, it can be\nslower as XP 64-bit Edition runs the CPU is in "Long" 64-bit mode, but\nthe applications are still 32-bit with 32-bit libraries. Make no\nmistake, XP 64-bit Edition is heavily 32-bit and that's unlikely to\nchange for compatibility. The reviews on AnandTech's site show how\nlittle difference there is in XP v. XP 64-bit.\n\nSo Sempron v. Athlon 64 is really just a matter of cache size.\n\nBut if you run Linux, nearly all libraries and software shipped in a\nLinux/x86-64 distro are 64-bit (with a few, common 32-bit libraries).\nWith source code and the 64-bit "clean" GNU Toolchain which almost\neverything is written to, this is easy for the entire Linux world to\ndo. The performance difference is staggering as shown on AnandTech's\nsite of Linux/x86 v. Linux/x86-64.\n\nSo Sempron v. Athlon 64 now becomes a 64-bit performance consideration.\n\n- So what should you buy? Depends.\n\nFor maximum performance, it's no so much the CPU, but the Socket.\n\nSocket-939 sports (2) DDR400 channels segmented from (1) 2000MT\nHyperTransport channel. The total aggregate throughput is up to\n2*3.2GBps+8.0GBps = 14.4GBps (DDR400).\n\nSocket-754 sports (1) DDR400 channel segmented from (1) 1600MT\nHyperTransport. The total aggregate throughput is up to 3.2GBps+6.4GBps\n= 9.6GBps.\n\nSocket-462 is the legacy "front-side bus" (shared memory-CPU-I/O)\napproach upto DDR400. The total aggregate throughput is up to 3.2GBps.\n\nIn the case of Windows, which is really 32-bit even if you run XP 64-bit\nEdition, Sempron is really just a cache size issue versus Athlon XP/64\n(and socket) and nothing else as far as the CPU itself. So the only\nother difference is the total aggregate throughput of the Socket as\nabove.\n\nIn the case of Linux, which is true 64-bit in Linux/x86-64, Sempron now\nbecomes a performance hit versus Athlon 64 (64-bit, Socket-939/754),\nalthough relatively unchanged versus Athlon XP (32-bit, Socket-462), in\naddition to the cache size and total aggregate throughput.\n\n- Socket-754 Sempron v. Socket-939 Sempron\n\nAccording to the AnandTech review, the 0 Socket-754 Sempron 3100+\nperforms around the same as the 0 Socket-754 Athlon 64 2800+ in\n32-bit Windows. It doesn't save you much, so it's a toss up for\nWindows. But for Linux, you probably want to splurge the extra .\n\nIn reality, the Socket-939 with its two (2) DDR channels and slightly\nfaster HyperTransport is the real winner for _any_ OS, especially\nworkstations that throw a lot of data around (or servers for that\nmatter, although you'll want more I/O options, which is another story\n..\n\nBut you'll pay for it as Socket-939 Athlon 64/FX processors or more\ncostly than their Socket-754 bretheren. But soon there will be a\nSocket-939 Sempron, which brings us back to what OS you will run? If\nyou run Windows, then Socket-939 Sempron might be "the cheap bomb," but\nfor Linux, Socket-939 is probably worth going with even the lowest end\nSocket-939 Athlon 64.\n\n- SIDE STORY: Issues with 64-bit libraries and 32-bit applications\n\nOne of the main reasons Microsoft doesn't want to tackle a true XP\n64-bit is because of the support issues. First off, their entire\ntoolbase is not 64-bit "clean." Complicating this is the fact that when\nthe AMD x86-64 is in "Long" mode, you cannot have 32-bit applications\ncalling 64-bit libraries -\- at least not without the library being\nmodified.\n\nThe GNU Toolchain (Linux is a GNU system, and many other UNIX systems\nare GNU compatible these days) has been 64-bit "clean" since the\nmid-'90s. If the source code is available, the program can typically be\nrecompiled for 64-bit, and use the 64-bit libraries, without issue. In\nother words, there's probably a 64-bit version out there that is easy to\nfind, or can be built easily for Linux/x86-64 (without all that techie\nstuff .\n\nYou see, in Linux, most programs are written by developers to use GNU\nAutoconf. Using GNU Autoconf means it's not only "portable" to 64-bit,\nbut even non-PC platforms. If GNU Autoconf detects /[usr/]lib64, it\nwill attempt to build against it and create a Linux/x86-64 "target"\n(i.e., a true 64-bit version of the program using those 64-bit\nlibraries). In other words, if you use an RPM distro, you build the\nbinary version of programs from the same Source RPM (.src.rpm) file,\nwith the same _single_ command (e.g., "rpmbuild -bb program.src.rpm") as\nfor 32-bit x86 (or any non-PC architecture for that matter).\n\nThat usually takes care of it, 0 issues.\n\nIn the rare case of a Linux application (typically a binary one without\nsource code -\- like a commercial program) requiring 32-bit libraries,\nthe Linux/x86-64 distro may already include them. Applications that\nuse Linux/x86-64 libraries link to those in /[usr/]lib64, and those that\ndon't link to /[usr/]lib, the latter being the same as 32-bit x86. If\nthe distro doesn't include the 32-bit version required for an\napplication, automatic fetching and dependency checking becomes easy\nwith APT/YUM commonly used by modern Debian or Red Hat platforms (among\nothers).\n\nIn other words, a Red Hat Linux/x86-64 system (Fedora Core x86-64 or\neven Red Hat Enterprise Linux WS/AS x86-64) could fetch the 32-bit\nlibraries from the 32-bit Fedora Core/Extras repositories via its normal\nmethod with APT or YUM. The process is very transparent altogether to\nthe user. Likewise, in the case where source code _is_ available, APT\nor YUM could be used to fetch the source RPM (.src.rpm) and attempt to\nbuild and install it against /[usr/]lib64.\n\nSource code is so rare in the Windows world, and the Microsoft Toolchain\nis not 64-bit "clean" except for some core components, it's virtually\nimpossible for Microsoft to do the same. Hence why XP 64-bit is still\nheavily 32-bit. So even though AMD x86-64 is x86 compatible, there is\nstill the issue of 32-bit programs being unable to use 64-bit libraries,\neven if the 64-bit "kernel" of the OS can run 32-bit programs.\n\nConfused yet? Don't worry about it, the Linux/x86-64 distros hide the\nmajority of this from you. I just talk about it for completeness.\n\n\n-\- Discussing distributions is like discussing political parties. Not\nonly do they enflame people, but they often break down into sets of\nblind assumptions. Instead, people should focus on the specific details\nof underlying technologies, just like one should when it comes to\nspecific terms in legislation. Because the similarities are often more\nsurprising than the differences.\n-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- Bryan\nJ. Smith, E.I. [email][/email]\n_______________________________________________ PC_Support mailing list\n[email]PC_Support@matrixlist.com[/email]\n[url]http://www.matrixlist.com/mailman/listinfo/pc_support[/url]"