Hardware Analysis Community Forums http://www.hardwareanalysis.com/content/topic/5107/ 2008-11-23T04:43:23-05:00 http://www.hardwareanalysis.com/content/topic/5107/ http://media.hardwareanalysis.com/halogo.gif text/html 2003-02-24T23:47:25-05:00 gavin stanton http://www.hardwareanalysis.com/content/topic/5107/#24144 brief addendum,<br /> <br /> 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.. text/html 2003-02-24T23:38:01-05:00 gavin stanton http://www.hardwareanalysis.com/content/topic/5107/#24142 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... text/html 2003-02-24T13:00:53-05:00 Alan Taylor http://www.hardwareanalysis.com/content/topic/5107/#24074 I'll throw in an additional generic point about 64bit CPUs.<br /> <br /> 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.<br /> <br /> 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).<br /> <br /> 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. <br /> <br /> avt text/html 2003-02-21T21:49:31-05:00 Jim Hackenberg http://www.hardwareanalysis.com/content/topic/5107/#23678 Don't forget the Demo CPU might have a minimal Cache or other limitations just in case people did do that text/html 2003-02-21T09:13:56-05:00 Heinz Schenk http://www.hardwareanalysis.com/content/topic/5107/#23555 <a class="ext" href="/action/r/http://www.theinquirer.org/?article=7886," target="_blank">http://www.theinquirer.org/?article=7886,</a> update<br /> (referring to some /. discussion)<br /> <br /> [...]<br /> 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.<br /> <br /> He went on to point out that every part of the system was effectively a beta version. &quot;This is a prerelease version of the game running on a prerelease version of SuSE running on prerelease drivers running on prerelease hardware.&quot; text/html 2003-02-21T02:55:36-05:00 David Anderson http://www.hardwareanalysis.com/content/topic/5107/#23519 Right on the mark. The bottle neck is both the hardware and the software<br /> <br /> 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. text/html 2003-02-21T02:38:38-05:00 MrBungle http://www.hardwareanalysis.com/content/topic/5107/#23515 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.<br /> text/html 2003-02-21T01:53:07-05:00 Methos Nethos http://www.hardwareanalysis.com/content/topic/5107/#23513 I'm surprised no one has speculated that the Antialiasing and Anisotropic Filtering wasn't turned up to full on the video card. text/html 2003-02-20T23:25:13-05:00 gary ford http://www.hardwareanalysis.com/content/topic/5107/#23494 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. text/html 2003-02-20T21:50:26-05:00 jason nourse http://www.hardwareanalysis.com/content/topic/5107/#23469 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 <img src="http://media.hardwareanalysis.com/smilies/smile1.gif" width="14" height="14" border="0" alt=":)" title=":)"> text/html 2003-02-20T18:14:51-05:00 Heinz Schenk http://www.hardwareanalysis.com/content/topic/5107/#23424 aren't you?<br /> 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.<br /> <br /> No one, even not in Satan Clara, believes that a 1.6 GHz P4 could even come close to a 2 GHz K8.<br /> <br /> So these 'benchmarks' are simply not usable for comparison. <br /> 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) text/html 2003-02-20T17:59:38-05:00 David Anderson http://www.hardwareanalysis.com/content/topic/5107/#23420 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).<br /> <br /> <br /> 64 bit is about math and memory right? Well how many prime 95 packets can it process in an hour? <br /> <br /> Or is this a problem with client programs like prime95 not having a 64 bit version to build? text/html 2003-02-20T17:40:31-05:00 Tony Lodise http://www.hardwareanalysis.com/content/topic/5107/#23419 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. text/html 2003-02-20T16:02:15-05:00 Keith Constable http://www.hardwareanalysis.com/content/topic/5107/#23401 Please keep in mind that the Linux build of UT2003 is considerably slower than the Windows build.<br /> <br /> Probably due to some DirectX stuff that doesn't transfer over well to OpenGL. text/html 2003-02-20T15:37:56-05:00 Tim http://www.hardwareanalysis.com/content/topic/5107/#23391 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.