How exactly is a video-card benchmark supposed to tell us anything about a CPU? Today's first-person shooters are bottlenecked by the video card, not the CPU. Why are they hiding behind video-card benchmarks? What are they trying to hide?

-Raystonn

they're not trying to hide they just have nothing to show

They need a more CPU oriented benchmark running like Prime95, PCMark, and/or SiSoft Sandra's CPU/CPU Multimedia benchmarks.

At any rate, we'll see how well this technology performs under 64bit WinXP, instead of 64bit Linux soon.

Yes, we need more benchmarks. And different benchmarks.
meassuring cpu/fpu performance, memory, videocard, I/O performance. The overall performance depend on what you intend to do with the machine. Some people only run floatingpoint operations on small datasets that fits into cache memory, others would like to see how the system performes with heavy i/o.

maybe trying the Seti benchmark would work better?
i find that its a very good demonstartion of how well a system works without having to worry about the graphics card being a bottle neck

I don't think the low benchmark was the fault of the Vid Card, as its a Geforce 4 TI 4600, its a bit too new to be a big bottleneck like that. They should have gotten at least 75fps min if they used a P4 at a lesser speed, so its the processor. They're probably still dwelling on bus speeds in the area of 300 - 400mhz with that processor I would bet.

Please keep in mind that the Linux build of UT2003 is considerably slower than the Windows build.

Probably due to some DirectX stuff that doesn't transfer over well to OpenGL.

Well, UT 2k3 may just be a game, but for a game it is very cpu dependent, considering the game physics. Of course it isn't a benchmark I would choose to test a cpu on. You gotta keep in mind that this is running off Linux, not windows xp (which is what most benchmarks are based on). Hopefully this isn't a foresight into how well the Athlon-64 will perform, because I wasn't impressed at all.

Wow that much Hardware and all they did is play a game...Thats like buying a Dodge Viper GT and test driving it in a school zone to test its abilities (by going the speed limit).


64 bit is about math and memory right? Well how many prime 95 packets can it process in an hour?

Or is this a problem with client programs like prime95 not having a 64 bit version to build?

aren't you?
There's a whole LOT of things that might hold the numbers down: The X86-64 Versions of a) UT 2k3 b) Mesa (XFree OpenGL) c) XFree Drivers by nVidia are all not very mature by now are they? How could they? I don't know anything about the Linux Performance of UT either.

No one, even not in Satan Clara, believes that a 1.6 GHz P4 could even come close to a 2 GHz K8.

So these 'benchmarks' are simply not usable for comparison.
Please be calm and wait. We'll see numbers for release-quality Software (and Hardware) when they are released. (Yeah I know the nVidia Drivers *are* released, but it's the very-first release)

im sorry but i have to rant for a sec. first, that wasn't the cpu slowing things down, it WAS the video card. First the article didn't state whether they were ussing the nvidia kernel drivers for the card to provide a truely accelerated xsession. If they were just runnning xwindows using the nv option then that explains the horrible fps rates. And second, on linux, Nvidia cards suck with out MASSIVE tweaking to the system. This will be the only time you'll here me say this but for that system setup they need to run the benchmarks in windows to get more acurate specs since nvidia cards are truely made with windows in mind. of course that means they have to wait for MS to get their new junky os out

whoever said the linux build of ut2003 isnt as good as the windows one either hasnt tried both or is a gh3y homo smoking pot. i get like 10-30 fps more in linux than in windows(xp). it most likely indeed is the fact that games are more dependant on the vidcard, not cpu, and the 64bit programs for linux arent very mature yet. why the hades didnt they do something that would test the cpu, not the vidcard? gh3y morons. oh and that laptop looks sweet, give me one.

I'm surprised no one has speculated that the Antialiasing and Anisotropic Filtering wasn't turned up to full on the video card.

just because a processor has more bits to it won't necessarily make it faster. what will matter is how many calculations per clock cycle it can do. The more bits a processor has will just allow the thing to move more data per clock cycle. So a 64 bit chip only gains an advantage over a 32 bit system when dealing with chunks of data or memory addresses over 32 bits long. If you had ever programmed in assembly you would know this. It will take a 64 bit chip just as many cycles to process a 4bit chunk of data as an 8 bit processor 1 cycle. So one would think that the reason that the athon 64 was not working far better than a P4 with the 64 bit compatable version of UT2003 is that the software is just a 32 bit crossover version. if they were to make a 64 bit optimized version it would probably be exponentially better than the winXP version of UT2003.

Right on the mark. The bottle neck is both the hardware and the software

Until programs are recompiled for 64 bit advantages you don't get any more performance. This also allows for large numbers natively...Physics engine or not it's not pushing that.

http://www.theinquirer.org/?article=7886, update
(referring to some /. discussion)

[...]
The developer pointed out that the OpenGL code for UT2003 is slower than the D3D code at the moment. So you would need to run the OpenGL version on Windows to start to get a fair comparison.

He went on to point out that every part of the system was effectively a beta version. "This is a prerelease version of the game running on a prerelease version of SuSE running on prerelease drivers running on prerelease hardware."

Don't forget the Demo CPU might have a minimal Cache or other limitations just in case people did do that

I'll throw in an additional generic point about 64bit CPUs.

Comparing 64bit versus 32bit addressing, your pointer size doubles - so there are often application dependant negative performance hits associated with this - memory efficiency can decrease in terms of space used, and latency - in fetching larger pointers from data structures. This has been demonstrable from the days of the early Ultrasparc processors.

Unless your application requires addressing huge amounts of physical/virtual memory, or really needs to use huge integers there is no pressing technical reason to use a 64 bit processor in the domestic market (I acknowledge there may be niche benefits of larger data registers in providing wider targets for SIMD instructions).

What will be of benefit is the additional architectural improvements of a next generation CPU core, and any improved process technologies that it may be manufactured with. These improvements often offset with interest the negative aspects.

avt

Personally I am under the impression that, since there is no current instruction set code 64 bits long, virtual cpus like intels hyperthreading technique are much more reasonable at this point. Software applications dont require optmizations to utilize this virtual dual processor environment, since operating systems delegate threading to the virtual cores. Of course, im referring to operating systems such as xp and so on...

brief addendum,

I would currently pit any 64 bit processor without hyperthreading against a 32 bit processor with a 6-800 megahert disadvantage that has HT enabled. This is not accounting for factorssuch as memory latency and bandwidth... I'm assuming all things equal outside the CPU's..