Slashdot Mirror
Athlon 64 Debuts
SpinnerBait writes "AMD launches their Athlon 64 and Athlon 64 FX chips today and there is
a full analysis with benchmarks up at HotHardware. Interestingly
enough, Intel pulled a fast one (literally) and released a new breed of Pentium
4 chips with 2MB of on board L3 cache, just in time to boost their performance
in the benchmarks for this launch. Regardless, the performance levels for
AMD's new flagship look very strong." Tom's has a story, or Tech Report, or see info straight from AMD.
And Anandtech has a good article up, as well.
$8.95/mo web hosting
Here are some more benchmarks
AMDzone
AnandTech
XbitLabs
Ace Hardware
There are even more at AMDZones main page.
HardOCP
Tom's hardware
Ace's Hardware
As you would expect, no chip is dominate. though the more interesting thing for me than the nip and tuck between $800 CPUs, is the Athlon64 3200+ performs right there with the 3.2C in mosts lets. Not bad considering it retails for more than $100 less.
Remember, it will be a while before hardware is supported properly on it. Somebody on OSnews.com has reported problems installing linux on his Opteron (Server version of A64) machine.
1) Application Programming
2) Ssytems Programming
3) General Purpose and System Instructions
4) 128-Bit Media Instructions
5) 64-Bit Media and x87 Floating-Point Instructions
Get them here.
Then go make your favorite compiler or windowing system work better on this.
See what I've been reading.
There's a limitied supply, but they're available. Here's one: Athlon64 3200+ bundled with a MSI K8T Neo-FIS2R, in stock and available, for "only" 6600SEK (~$835 /w tax)
I'm salivating, but the limited supply is going to keep the price way, way up for a time.
Belief is the currency of delusion.
With regards to the OS, here's just a little more interesting plot info. I just noticed that Internet.com has this article which mentions that Microsoft launched the official beta of Windows XP 64bit as a "precursor" to AMD's launch today.
;)
AMD! Don't cater to the evil Redmond mole-men!
If this is a paper launch, Alienware is selling some interesting paper.
You can get Windows 2003 Server and Windows XP 64bit 2003 Edition from the MSDN Website (assuming you have an account).
Drivers are not to hard to get on the linux side. There is a x86-64 nvidia driver. As far as other drivers.. all in the kernel baby. Doom3 will run on the processor but it most likely will be a 32bit build. I would not be suprised at all if there was a x86-64 build and even a smp x86-64 build.
There's boards out from MSI, Gigabyte, Shuttle...
*shakes head*
This sure looks like a motherboard that supports the Athlon64, shipping same business day.
Ita erat quando hic adveni.
Looking for a Linux/Windows/Mac admin/support tech monkey in the Los Angeles area? Please see my resume.
Microsoft 64 2008?
XP 64bit Edition has been out for a couple of years now for the Itanium processors. Just waking up or just not into the 'computer' thing?
For the AMD (64bit extended) processors, SP1 beta, which includes the AMD 64bit version is already out in most tech labs.
We are running it here even and it is even available to MSDN subscribers.
Considering we haven't even posted a bug for it yet, I would say, that not only is it working well, it will hit the release schedule later this year.
Athlon 64 can run 99 percent of Commodore 64 software in emulation, including the C=64 version of the Contiki OS. In addition, it can probably run almost all these other ports.
You want native? If the Athlon 64 processor and chipset can boot up as a normal x86, it can run Contiki for PC DOS.
Will I retire or break 10K?
Check Pricegrabber, PCSuperDeals.com is showing 83 units in stock at a price of $454.28 for the Athlon64 3200+
It is already available at newegg.
here
If you implement x86 with PAE then you get 8gb.
You also get horrible performance and require different compile flags for the application.
Compile something for x86-64 and you get 48-bit addressing out of the box with no performance hits and no special flags.
here
it looks pretty interesting and it's pretty reasonably for what it is at $1650 including a dvd burner;
AMD Athlon(TM) 64 3200+ PC Processor
3 IEEE 1394 Firewire Ports
512 MB DDR 333 main memory (2 GB Max)
10/100 NIC Port
160 GB Ultra ATA/100 Hard Drive
128 MB 8X AGP ATI Radeon 900 SE Video Card
17" Monitor (1280 x 1024 Res.)
1-Year Limited 24Hr/365 Day Tech Support click here to upgrade the monitor
30-Day Money-Back Guarantee Details
56K Max v.92 Send/Receive Fax Modem
DVD-RW with Ulead VideoStudio 6
DVD Bonus Software: DVD X Copy Xpress
Microsoft Windows XP Home Edition
4 USB 2.0 Ports
Creationists are a lot like zombies. Slow, but powerful and numerous. And they all want to eat our brains.
32 bit = 4294967296 possibilities.
64 bit = 18446744073709551616 possibilities.
Your simplification of 64-bit processing is quite astounding. If your simple logic was indeed correct I'm sure Intel, Motorola, AMD, would be creating 128,256,512-bit systems by now and we would be living in a grand age of no disease, no war, and no death...
In fact the arguement for 64-bit processing is much more complicated. Simply put, 64-bit processing allows you to do two main things:
1. Move more data in one clock cycle
2. Perform more complicated instructions in one clock cycle
The first of which is widely accepted to be a good thing and the second is not so widely accepted (due to heretics like Hennessy...jk).
Where the Music Matters
No, PAE does not allow a single program to access more than 4GB, only the OS. So while they were stupid to add the physical portion to the address space tag they were basically correct. How many people that run applications that need 4GB or more of ram run more than one at a time? Basically anyone who needs more than 4GB needs it available to just one app so PAE is worthless in most cases.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
IA-32 Intel Architecture
There is also a good deal of pdf manuals, and I'm sure that more hardcopy manuals would be avalible if I actualy cared to look.
I don't want to bother going over the implications here...those that know them, do...
Fortunately, you're not one of those.
64-bit computing is not a clear win in and of iteself. If you're merely doing 32-bit calculations then odds are a true 64-bit CPU will be slower, because to do the same work you have to move twice as much data to do it -- you have to fetch a 64-bit operation instead of a 32-bit one, and ditto for data. Presuming that the actual operation takes the exact same amount of time per bit then your 64-bit CPU would be half the speed of the 32-bit CPU because it has to do twice as much work for the exact same result.
Of course, that's the simplistic case and ignores the actual case at hand. AMD's x86-64 is not a pure 64-bit CPU because it doesn't need to be. The x86 ISA is ungodly ugly (which is why nobody implements it anymore -- it may look like x86 ISA on the surface, but there isn't a modern CPU that actually implements the x86 ISA in the CPU core) and x86-64 operators are only ~10-15% longer than traditional x86 operators on average. So your operator length didn't double, and you don't need to double your instruction or combined cache just to maintain parity with old CPUs. Additionally, the current x86-64 spec only implements 48-bit addressing, which should be more than adequate for about a decade or so, so address fetches only increase in size by 50%, not 100%. Still an increase, but one that's fairly acceptable and it's a vast improvement for anytime you have to address anything >4GB in size (which is increasinly common, particularly for databases). On top of that, x86-64 adds 4 general purpose registers, which doubles or more the numper of GPRs available (the "or more" bit depends on the operation you're performing, since some of the GPR's in x86 aren't entirely GP). Yes, all modern systems have register renaming. Doesn't help much when you still only have a handful of registers available to a single process and it has to deal with only those -- the assembly code cannot know about the virtual registers, otherwise they wouldn't be virtual!
As far as the data goes, you don't have to perform 64-bit operations on all the data, nor does all of the data have to be 64-bits wide. Clearly how much impact this has will vary from program to program, but unless you're doing a bunch of operations on long long's (64-bit integers) then you probably won't see much performance difference in raw computing speed. In fact, because of the slightly larger operator size and the increased address size you're more likely to see a performance decrease, albeit a slight one.
There are some major weaknesses in the Prescott approach, even if it really does include 64-bit extensions of some sort. For example, the AMD design includes hypertransport and the integrated memory controller while Prescott does not.
As a result, the AMD design scales amazingly well while none of the Intel designs do. The scalability of the AMD 64-bit design has allowed it to obtain some absolutely amazing wins for supercomputers recently, for example.
Finally, AMD has plowed the field for its 64-bit extensions by providing first, emulators, then demo silicon, and now, finally, a shipping product. Intel's Prescott extensions are not even confirmed by Intel and are a LOOONG way from being supported in GCC or any current software. Intel can paste on some sort of unknown and undocumented 64-bit instructions in Prescott but they will be way too little and way too late. The only real significance of the Intel Prescott 64-bit stuff (assuming it is even real) is for its potential 'vaporware' effect on AMD's initiatives; i.e. it could cause people to delay getting an x86-64 CPU if they think that Intel will be releasing something 'real soon now.'
Not really. The P4 had a longer pipeline for the future, and when SSE2 was used, it had similar performance clock for clock. The K8 doesn't have such a design. Instead its an Athlon with a longer pipeline so they can ramp it, but with improved algorithms so the IPC is better (meaning it does roughly the same amount of work per clock as an athlon, but can ramp higher). With the 64bit mode, they have extra registers so there is a performance boost, and the memory controller is a nice add-on too.
.13 and SOI at the same time, causing major delays. They're just lucky Intel only caught up and they're still quite competitive.
The only "future in mind" would be through compilers making use of the 64bit mode more efficently. However, Intel has the same with the P4 and IA-64, as well as they actually build them unlike AMD. So, your statement is simply wrong.
AMD was supposed to release this chip months ago, but they screwed up trying to go
"Open Source?" - Press any key to continue
I'm seriously hoping that this isn't a paper launch.
Why don't you go go buy one from here or here and let us know?
First, we still don't have a mass market consumer OS for native x86-64
Very true. And some of us just don't care. I wanted benchmarks for GCC and OpenSSL and Postgres, and all they showed was 32-bit Windows apps, which nobody but nobody cares about. Well, life is tough, I guess.
There are mobile Athlon-64 CPUs.
From The Inquirer:
"First, off AMD has a mobile Athlon 64 reference design which includes 256MB of PC 2000 memory, the K8T400 chipset, and an ATI M9 graphics card. The mobile chip will be launched in September."
Actually, this is only partly true. Because the new AMD64 instruction set includes 8 more general purpose registers, compilers now generate far less load/store code during periods of register contention. This alone ALMOST makes up for the extra byte per instruction that 64-bit instructions require.
In other words, full 64-bit AMD64 instructions require slightly more bits per instruction than their IA32 equivalents to encode. But at the same time the TOTAL number of instructions in a given program has decreased because of less register pressure (which produces load/store code). These two competing factors tend to offset each other, although the presentation I saw indicated that the total code size has increased slightly (5% or so, IIRC).
You are correct in pointing out that the instruction cache will now be less effective because bytes per instruction have increased slightly. I assume instruction cache sizes will need to increase to compensate. But instruction memory bandwidth isn't really a huge issue anymore because instruction caches do such a good job of prefetching (and code accesses tend to be highly local, unlike data accesses).
this page you will see the following stupid comment...
Two dumb things about this...
1. UT2003 is made by Epic
2. UT2003 was a premier product that AMD was showing off as a 64bit application running under SUSE linux on the Opteron when it was released.
Two big mistakes