Slashdot Mirror
Opteron Gaming Benchmarks
bishop writes "Ace's Hardware has published some Unreal Tournament 2003 benchmark results on a 1.8 GHz Opteron 244. The Opteron servers out right now don't have AGP, but this issue has been nullified, literally, through the use of the 'null renderer' option in UT2003 to bypass the display output. At 1.8 GHz, the Opteron manages to outpace all previous Athlon models, though it does still fall behind the 3 GHz Pentium 4 by about 8%." Only 8% slower in performance with a 40% slower clock speed. Not too shabby.
I can't wait till the Athlon-64's come out! Maybe they'll be able to surpass a P4 3ghz?
One Function explains it all ...
bltMegsOfTextureMaps(...) {
return;
}
"hum, nah, that shouldn't mess up the results..."
You know, I find it pretty interesting how vastly AMD's chips outpace the P4 clock-per-clock.It's widely acknowledged that the P4 gets less done per clock than the P3 did. Some people have said that the P4's memory architecture is a disaster, or that it is pipelined TOO deep, but I've got a sort of conspiracy theory about this. Granted I'm not a computer engineer, and know just enough to hang myself with, but here goes:
I think they've manipulated the design so they can deliberately increase the clock rate for marketing reasons, without getting proportionally more performance out. Basically I suppose they've taken the longest paths through the chip and stuck latches all over the place so that the overall cycle time can be reduced, but operations that used to take one clock cycle now may take two. When 1.8 GHz AMDs can nearly match the speed of a 3 GHz P4, I don't think this is an entirely unplausible theory.
On the other hand, maybe the P4 really just is a pig. There was some discussion on usenet a while back about how it takes upward to 2000 clock cycles to enter and exit an interrupt handler on the P4, something which an old 486 could do in ~45 cycle IIRC (and I don't recall exactly, but I think the Athlon today can do an INT/IRET pair in a few hundred cycles). Curious how in hyper-optimizing these chips for the most common cases of execution, performance of these sorts of periphery operations goes all to hell.
That said, I'm really looking forward to having 64-bits on the desktop. =)
I'd pay 50 dollars!
I'll run out and buy one for my blind neighbor.
so I can cream him on tokara forest.
Maybe I can hook up a more advanced version of
that cool braille output doohickey from the
movie sneakers so he can feel the pain with
his fingers.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
I think the Opteron has the potential to do a lot more than be a gaming spectacle, but clearly, between the preliminary SPEC marks, various performance metrics on database machines, coupled with a real bus (hyper transport / alpha - like bus) and being reasonably competitive at a modest clock rate is impressive to say the least. And its ability to chew through legacy un-optimized code is leagues better than Itanium2, which is considering an FX!32 like on the fly "re-compiler" to help with horrific performance.
The novelty here is "I can run junk binaries and be very good at big applications at the same time."
Since when has a potential piece of server iron ever run a gamer benchmark well? The versatility of the Opteron is apparent right out of the floodgate.
This industry needs a bit of boat rocking right now. I will sit back and watch the competition, but this Opteron is quite possibly the first step in de-cheesing and de-crudding the horribly "consumer" oriented PC design.
Sure, this isn't a SPARC,HP-PA, Power4 or a MIPS. But this is so less "gay" than Itanic2. This gives serious power to the masses at a great price. People, lets consider rewarding AMD.
Sun and IBM have both indicated that they will be coming up with designs around the Opteron recently. I remember wanting that Power4 a while back. I remember hoping Apple de-vaporized the 970. Now the Opteron is here, and well, I don't want to wait for a Power4 or a 970, lets take this baby and run with it.
You know, it's always saddened me that there aren't more multi-cpu motherboards for general consumption.
There's plenty of us that would stick another £200 CPU in the box every now and then as the cash came in.
I mean, I've already got more memory than I ever use and too much HD storage, I want CPUs I never use either.
I like my DUAL 1.2 Ghz p3 mb. I put it together for £300 or so and it's done sterling service, surpassing my normal 18 month upgrade timetable and not looking like it's about to be retired any time soon. (until DoomIII & HL2 I guess 8).
I'll be looking to buy a nice 4-8 way Opteron system and populate it as I go along.
I think Intel missed an opportunity crippling their processors to be non SMP. I hope there's an engineering reason why. I can't really think of a good reason why otherwise, surely they don't make *that much* on gambling that I'll buy a expensive Pentium if I can't have a 4 way Celeron set-up.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Oddly enough, Anandtech's numbers show the complete opposite: The Opteron beat ALL other CPUs at ALL games. Including the P4 3.0C in UT2K3. Take a look:
http://anandtech.com/cpu/showdoc.html?i=1818&p =6
The second reason is because of the interrupts. In a dual-CPU machine, one CPU can be getting hammered by interrupts, and you still have another to run other code, such as your GUI.
True to a point. There must be a working/efficient APIC and the OS has to properly manipulate this for both CPUs to service interrupts. While I strongly agree with a 2-way system being leagues better than "faster" single boxes, there are big-time problems with various OSes including Linux where say, putting a GigE card in, then putting it in promiscuous mode, then sending 200,000 packets per second at the box causing complete and total livelock. The problem comes with the ability for interrupts to very easily monopolize the whole system. Other architectures have solved this problem with things like crossbars, more efficient busses, etc.
I am hoping the Opteron will handle IO better - a lot better. We have a very nice Serverworks dual P3 implementation right now with 64bit 66MHz PCI cards (E1000, 3C996). It is fairly easy to send enough traffic to livelock the box. The CPU is cold to the touch, its not doing anything, but it is live locked. So, with the APIC turned off, 1 CPU is 100% used up by interrupts. With it on, 2 CPUs are 100% used up by interrupts. Interrupts steering isn't an availability guarantee is my point.
I have solved problems with a polling feature available in FreeBSD, where you can set the maximum amount of CPU time (interrupts fall under "system") that the network driver can take up. The point is to have the ability to set a fraction of the CPU aside for userland. This is very useful for network applications that require seeing lots of traffic, like Snort, but need CPU to do other things.
The point is that the PC architecture is seriously flawed in many ways. If you crack open the hood of a Juniper you'll see a "PC brain" running FreeBSD, but they solved these crazy architectural flaws by having network processors. Everything is co-processed in Juniper land.
Unfortunately, even the best NICs with interrupts coalescing and all the CPU cycle saving junk turned on doesn't help for network applications that need to see it all.
I'm hoping for better IO and better 2/4 way performance from Opteron, and I think it will deliver. Given that UT2003 is completely un-optimized for Opteron yet Opteron can play ball with what it considers "junk binaries" is impressive.
All in all, I must say, the minimum number of CPUs for anyone who is in the slightest technically inclined is 2.
The situation with the gigE cards isn't entirely the fault of the OS (although the OS certainly isn't blameless). GigE cards simply generate *swamps* of interrupts. However, the nicer gigE cards give you the ability to turn on interrupt coallescing, where the card will queue up several packets before it sends an interrupt.
That does, of course, increase the latency, but unless you're in a clustering environment, you can generally handle a small hit in latency much better than you can handle a swarm of interrupts.
On the note of embedded PC architecture, yesterday I helped my boss crack open an old GPS to try and replace the interal battery. What did I see staring back at me? A 25 Mhz i386! It was, of course, in a *much* smaller package than the "regular" 386's were in, I suppose that Intel makes (or made) them on a smaller process for a while for projects like that. And I recall $15,000 Livingston PM3's which used an AMD 486. : )
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.