Slashdot Mirror
AMD Quad-Core Opteron (Barcelona) Tech Report
crazyeyes writes "AMD has been very tardy with Barcelona. Countless AMD fans have eagerly awaited a new processor. As the day draws closer, TechARP takes a look at the upcoming quad-core AMD Opteron. Is there more to it than just its four processing cores? Will it be the Intel-killer that AMD promised long ago? From the article: 'AMD is in the same boat as ATI. Delays after delays of their long-awaited Barcelona core not only ensured the dominance of their rival, Intel, in the desktop processor market, it also ensured that Intel would be the only choice for those who want a quad-core processor. Although that wait will end in August, 2007 when the Barcelona is finally launched, it remains to be seen if AMD's new processor will be able to inflict serious damage to Intel's dominance.'"
... it NEVER MADE _true_ QC CPU...
All existing Q6xx0 solutions are dual-dual core ie two dualcores sharing same FSB - and that is _NOT_ the same as true QC as Barcelona is claimed to be.
That difference is enough to make Barcelona the main choice for many core servers even if it were made with old K8 and not the new K10 cores.
Intel should have true QC chips in a year or so...
That's because you're not aware of the power of using the GPU in coordination with the CPU. Folding certainly shows GPU as a force not to neglect. You also fail to realize into your comment that quad cores are two dual cores. AMD and Motorola would do this sort of thing to claim next tier technology when in reality they were today's tech on steroids (They often fix GHz speeds with two CPU sets). Now, for some reason, AMD has opted not to do that and we'll see the true worthyness of this strategy with the release of the true quad core.
That said, the delay in developing these quad core procs shouldn't put that big a dent in the pocket / market share of AMD simply because it's a niche market that has yet to be widely adopted.
From what I've heard, the Intel quad cores are selling like hot cakes for running virtual machines.
And it's not only quad core, Barcelona also brings a bunch of core improvements, sorely needed to keep AMD competetive with Core2.
You also fail to realize into your comment that quad cores are two dual cores.
I know, and I also don't give a shit. I got a single-socket mobo and four cores running, you don't. I don't need a special and expensive dual-socket mobo, eATX case or whatnot. That's 99% of the advantage there already. The notion that "real" quad-core makes a big difference is at best disputed, maybe if you have a lot of core-core communication but well... I don't see how that could be a very big bottleneck for normal quad-core use. The Core 2 Quad is certainly not FSB starved, the advantage of 1333MHz over 1066MHz FSB was minimal. The cache tricks you can pull by reassigning the cache of all four processors is also minimal (we've seen this with single-core processors using varying cache sizes). There's just no big compelling reason for such tight intergration unless you're trying to build a cluster with lots of cores working on the same data.
Live today, because you never know what tomorrow brings
Native quad-core is better than dual-dual-core because more cores can exchange cache snoop data over CPU-speed internal buses instead of low-speed external buses. Cache snooping quickly kills performance scaling on shared FSB architectures like the P3, P4 and Core 1&2. Since the same FSB is also used for memory IO, cache snooping robs some more of the FSB-limited memory performance on P3/P4/Core-1&2 FSB-based SMP architectures.
Shared FSB systems do not scale... even Intel knows that. However, dual-dual-core is more profitable short-term and easily more than enough to give AMD a run for its money for a good while longer. Things will get really interesting after Intel's Nehalem materializes in late 2008... perhaps we'll see AMD get one-up'd like they were when Core2 came out last year.
Of course nobody's running 64-bit applications at home on at the office. Because the dominant player there is Microsoft — whose 64-bit support on the desktop is either lame (try to find even basic drivers for XP-64) or a nightmare (try to run Vista-64 at all!). Can't really run 64-bit apps without a 64-bit OS, can you?
On the other hand, there's a huge demand for 64-bit apps that run on high end workstations and servers. How do think AMD managed to grab so much market share so quickly? By finding a way to meet that demand ahead of Intel, that's how.
If it weren't for this demands I wouldn't have a job — documenting x64 servers for Sun. Yes, Sun. Its a big profit center for them these days.
All that tells us is that Gentoo 64-bit support sucks and that you're not supporting any high-end applications. What have you got, some low volume commerce and web presence sites? If you were doing millions of transactions a day, you'd be needing to squeeze all the performance out of your servers you could manage. Which is why the big boys run serious 64-bit OSs: RHEL, SLES, Solaris, Windows 2003.
1) What Linux/BSD people need is irrelevant, the market share is too low. (I run WinXP, Debian and FreeBSD, for the record)
1.a) Complex addressing modes are only good for people writing software in assembler - few are needed by C-compilers, and those are provided already anyways. They're also more silicon space that could be better used for wider ALUs/FPUs or more cache.
1.b) 4kB/4MB pages are already available. 8kB, while marginally nice, isn't really necessary.
1.c) 32-bit instructions are just being translated to micro-ops, just like 64-bit instructions during instruction fetch, the benefit would be marginal, while losing 32-bit compatibility.
1.d) Doubling pins means more layers in motherboards, skyrocketing the manufacturing costs. It's possible if you're ready to pay 300-500$ per motherboard, to produce those 10 layer monsters. It would also mean another new socket type.
1.e) Because the memory controller is on the CPU (on the die), this would also mean more traces on the PCB -> radically higher costs.
1.f) AMD-64 keeps things simple, at least compared to some unnamed competitor. *cough* Itanic *cough*.
2. New ISA is often a suicide. Ever heard about Itanium?
3. Biggest blunder AMD has done recently is dropping Socket-939 prematurely.
The market 'ooh'd and 'aahd' in delight of the new architecture, supposing that it would herald in a new era of computing in a similar way that the jump from 16 to 32 did.
The 80386 was introduced in 1985, but the transition to 32 bits in software was really only done in 1995. Windows 3.1, released seven years after the 386, still ran on the 286. Word 6.0 for DOS, released in 1993, still could run on an original 8086.
The first 64-bit x86 processors were introduced in 2003. If they "herald in a new era of computing in a similar way that the jump from 16 to 32 did", then there won't be a full transition until 2013. Maybe Microsoft will bother shipping a 32-bit OS then, but since any 32-bit machines will be six years old by then, I doubt it. And I'd expect more than four gigs on a desktop to be pretty standard by then, so there'll even be a demand.
The problem isn't that we don't need/want 64bit, it's that with Microsoft it is so damned hard to get to 64bit. My AS/400's been running 64 bit for something line 8 years now. The conversion was transparent. With Microsoft, I can no longer use my 32Bit antivirus. I can no longer use my 32bit device drivers and many don't offer 64 bit versions. WTF? Who thought that was a good idea? It doesn't have to be that way. But that's the hold up. I want 64bit so I can run more than 4GB of RAM. But I don't want to replace all my hardware to get there. My system's upgradeable for a few more years now. Once it's time to build a new system, then I'll go 64 bit. BTW - at work, we have VMWare running with 8GB of RAM. I believe this ESX server is 64 bit. We portion it out to serve up 32bit Windows hosts. Yea.
Amen to that. I've run both XP 32- and 64-bit on this machine, and now I'm giving Vista x64 a go. XP 64-bit is a total joke - driver support is almost totally lacking, and now with Vista, I doubt that manufacturers have much incentive to develop for XP 64-bit.
As for Vista x64, it has been a nightmare. Between crappy/non-existent drivers and all the programs that are either totally incompatible with Vista, or just won't run on the 64-bit version (no Cisco VPN client? WTF??), I'm left thinking I should go back to XP. Either that, or a long waiting game for Service Pack 1.
I now have a computer that has 1 GB more RAM than it did when running XP (grandparent is wrong on that count, XP 32-bit can't see all 4 GB of RAM because of PCI devices, etc.), but no Bluetooth, suspend-to-RAM that is completely broken, and virtualization that breaks the network driver after a reboot.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
Only a fraction of the 64-bit capable desktops and workstations are running 64-bit applications. What's more, there are very few mainstream 64-bit applications out there, despite the fact that for gaming, audio processing, image processing/photoshop apps, and video there would still be performance advantages (memory bandwidth and operation throughput), even if you don't yet have > 4GB of RAM.
As a veteran of the 16->32 bit transition (for that matter, the 8->16 bit as well), I've been wondering about this, as I would like to start to benefit, both as a programmer and user, of the benefits of 64-bit AMD and Intel CPUs. The comparison is admittedly a bit forced, as developers of 32-bit apps aren't being forced into programming using a segmented architecture as they were in 16-bit days.
Warning: Readers of the following will have to cope with the fact that the installed OS on virtually all PCs is Windows XP, 32-bit. (Please assume crash positions.)
This means that MS effectively has these machines "locked in" to 32-bit mode, until the user upgrades their OS to XP-64 (little motive) or Vista 64-bit (or one of the server 64-bit flavors) - wait, this sounds familiar...
"Sherman set the wayback machine to the early 90's, and the great 16->32 bit transition" You might recollect the introduction of the mighty 386 processor, extended memory modes, the Win32s API, but probably most importantly, killer apps like DOOM loading up their own 32-bit memory managers to sidestep the OS, which really wasn't ready to provide good 32-bit native support. Apps that did this completely took over the system, putting the host OS in stasis until the app was exited.
Sounds much like the same situation - the majority of users are running an OS that can't tap the full potential their CPU has to offer. So - why aren't we seeing similar application tricks, like those that enabled 32-bit protected mode now? The proposition of writing an application which would sidestep Windows XP 32-bit and set up a mini 64-bit host environment (not really a full OS) is not that radically different, right?
IIRC, one of the reasons that the 32-bit app could be launched this way was that there was a way to allow it to converse with the 16-bit drivers already installed for disk I/O, audio, video, etc. (I honestly don't know if this is possible to provide a bridge from 64-bit to the 32-bit drivers in the same fashion or not.) This made it feasible to write apps in 32-bit protected mode without having to write 32-bit drivers for every possible piece of hardware in the system.
I am also certain that XP, and most users, would not be nearly as tolerant of an application taking over the entire OS unless it had the same "quantum leap of experience" that a game like DOOM brought to the PC in it's day.
All that aside - I do wonder how often Vista 64-bit is being pre-installed on new platforms vs. the 32-bit edition. If users are not strongly encouraged to upgrade now, this will continue to be a barrier to introducing 64-bit applications to the mass market. (At least Vista licensing and distribution is such that an upgrade from 32-bit to 64-bit is free - although I'm not sure how painless it would be.)
Any sufficiently advanced technology is indistinguishable from a rigged demo. -- James Klass
No computer is future proof. You can get some extra months on one by buying above average, but the best desktop you can get today will still look sad in three years. Pay extra for bleeding edge if you want to but the best value is middle of the road and frequent upgrades.
If you had written that statement in the late 90s or even as late as 2002, I'd agree with you. But system performance stopped doubling every 18-24 months a long time ago. Now it's closer to 36-60 months (although dual-core and quad-core upsets the calculation) before performance doubles.
What I've seen over the past decade is that responsiveness determines how sad a system looks and feels. A single-core/single-CPU system can easily be bottlenecked by a runaway process or by an operating system that gives too much time to a greedy process and not enough to being responsive to the user. But once you start adding CPUs or cores, apparent responsiveness goes up quite a bit.
I have good reason to believe (I've used multi-CPU systems for 3+ years now) that the lifespan of a multi-core or multi-CPU machine is going to be quite a bit higher then you give it credit for. My 3-year old box still feels pretty quick because the interface (except where Windows is poorly designed) rarely blocks input. The new dual-core machines that I'm building today will probably remain useful for 8+ years because of having multiple cores.
And as always, having enough RAM is essential (2GB for a dual-core box is a useful mininum).
Wolde you bothe eate your cake, and have your cake?
Only a fraction of the 64-bit capable desktops and workstations are running 64-bit applications. What's more, there are very few mainstream 64-bit applications out there, despite the fact that for gaming, audio processing, image processing/photoshop apps, and video there would still be performance advantages (memory bandwidth and operation throughput), even if you don't yet have > 4GB of RAM.
It's not really compelling - plus or minus a few percent. And you need to test two binaries which is expensive. So unless you're absolutely forced to use more than 4GB per process, I think people won't bother.
"Sherman set the wayback machine to the early 90's, and the great 16-32 bit transition" You might recollect the introduction of the mighty 386 processor, extended memory modes, the Win32s API, but probably most importantly, killer apps like DOOM loading up their own 32-bit memory managers to sidestep the OS, which really wasn't ready to provide good 32-bit native support. Apps that did this completely took over the system, putting the host OS in stasis until the app was exited.
Sounds much like the same situation - the majority of users are running an OS that can't tap the full potential their CPU has to offer. So - why aren't we seeing similar application tricks, like those that enabled 32-bit protected mode now? The proposition of writing an application which would sidestep Windows XP 32-bit and set up a mini 64-bit host environment (not really a full OS) is not that radically different, right?
If you really want 64 bit, I don't see why you can't use Windows x64. Sure you'll need to be careful that you have hardware which has x64 drivers, but that's life.
32 bit Windows already has PAE which is the moral equivalent of a Dos extender. I think Outlook and MS SQL server can use it. So there isn't really a hole for a 64 bit Windows extender.
I've often wondered what would happen if you could make bootable games - e.g. Linux+ATI and NVidia drivers+a game binary on a LiveCD. But to make it work you'd need to be able to offer much better graphics performance than regular Windows, just like Doom's extended Dos had better performance than regular Dos.
And given the amount of effort NVidia and ATI spend on Linux drivers compared to Windows ones, I'm not sure that's the case. DirectX is thinner layer over the driver than OpenGL too.
You'd also need to make a LiveCD which could boot on all PC hardware without any fiddling around with config files, which is probably non trivial given that new PC hardware is lauched all the time and OSs needed to be patched to support it.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;