AMD-64 Compiling Quake1

MajinChewY · Sep 26, 2003

Shure we have all seen the benchmarks of AMD-64 running 32 bit software on a 64 bit OS. But the question remains, how much of a performance benefit can we expect in games, by a program taking full advantage of the CPU. Someone should compile quake1 since its open sorce and find out. I hear their are problems with vid card drivers on WinXP64, but using software rendering would stress the CPU just as much if not more anyway.

Guest · Sep 26, 2003

Though I doubt Quake1 benches would be very represenative, it sure sounds like a damn good idea to me 😀

= The views stated herein are my personal views, and not necessarily the views of my wife. =

MajinChewY · Sep 26, 2003

It needs to be benchmarked on an amd64 machine, compiled to take advantage of the amd64 arcitecture, and on a regular version of winxp without the overhead. This would be the best way to compare performance.
Edited by MajinChewY on 09/25/03 10:36 PM.

phsstpok · Sep 26, 2003

Shure we have all seen the benchmarks of AMD-64 running 32 bit software on a 64 bit OS. But the question remains, how much of a performance benefit can we expect in games, by a program taking full advantage of the CPU. Someone should compile quake1 since its open sorce and find out. I hear their are problems with vid card drivers on WinXP64, but using software rendering would stress the CPU just as much if not more anyway.

<A HREF="http://www.lostcircuits.com" target="_new">LostCircuits</A> hints at this. They had a 64-bit copy of Unreal Tournament (not part of their review) but it performed worse than 32-bit version, both running in WindowsXP-64. Commanche 4 (32-bit) also lost performance running Windows XP vs running in WindowsXP-64. [<--edited for clarity]

They did say it could be a driver issue. Too early to tell.

56K, slow and steady does not win the race on internet!Edited by phsstpok on 09/25/03 11:11 PM.

MajinChewY · Sep 26, 2003

Any 32 bit program running in a 64 bit OS will preform worse. To my understanding theirs also a driver issue with nvidias 64 bit driver, reducing performance about 25%. This is why quake1 needs to be compiled and benchmarked in software mode. This is probably even a better test since the FPS will resemble what the CPU can render, not the video card.Edited by MajinChewY on 09/26/03 00:32 AM.

phsstpok · Sep 26, 2003

UT was compiled 64-bit. LostCircuits has that version. It still ran slower.

They implied with correctly working drivers, etc that 32-bit apps will run about the same. One application, Amorphium3, ran one percent better in compatibility mode than in legacy (protected) mode.

Guess we will have to wait for production WindowsXP-64 and drivers to know for sure.

56K, slow and steady does not win the race on internet!

scottkli · Sep 26, 2003

Whats up with Linux in this whole thing, I keep hearing about Win64 this and that in reguards to AMD64. Why not test the Athlon64 in a Linux enviorment?

phsstpok · Sep 26, 2003

I'm not a Linux user (I have Debian installed but I don't use it) so I don't know but has an A64 compiler been released yet? I guess there must be one by now. Opteron has been available for months.

I don't imagine it will be long before we see some Linux benchmarks.

56K, slow and steady does not win the race on internet!

TknD · Sep 27, 2003

A straight compilation from 32bit to 64bit won't guarantee a performance boost. For example, if a 32bit operation is only necessary but during recompilation, the 64bit operation is used, then obviously performance decreases. Porting it or getting it to work is the easy part with AMD64, optmizing isn't as straight-forward.

Also, it's not a good idea to really take the current winXp 64bit beta releases as real benchmarks yet. Drivers aren't finished and the OS isn't complete. So it's not surprising that UT 64bit would run slower.

What you can do is look at some linux benchmarks (which do exist but very few).

Slowly new AMD64 software is being ported and optimized.

c0d1f1ed · Sep 27, 2003

Quake 1 can't be used for a performance comparison because its bottlenecks are hand-optimized x86-32 assembly written by Michael Abrash [edit: not John Carmack]. So it would not benefit at all from the extra registers AMD 64 offers if you recompile it. The only way to do it would be to manually rewrite it for x86-64, but the algorithm's complexity is just too low to take advantage of it.

What would be a much better tests is [shameless plug] my own ps 2.0 emulator: <A HREF="http://sw-shader.sourceforge.net" target="_new">swShader</A>. It run-time compiles shader file into an x86 pixel pipeline. With some minor modifications it could take advantage of the extra MMX and SSE registers AMD 64 offers.

But I have to note that it doesn't very often run out of registers. It uses the 8 available registers on x86-32 as optimally as possible with an automatic predictive register allocator. Even when using 100 texture lookups (yes, it's unlimited), spilling and re-loading operations are very sparse.

So I believe there are many algorithms already work near optimally when optimized for 8 registers. Of course, extra registers never hurt, but it's not like it will double performance. Only for the general-purpose registers it's a bit different because mostly esp and ebp are already used for stack operations so x86-32 only has six usable registers left...Edited by c0d1f1ed on 09/27/03 08:11 PM.

MajinChewY · Sep 27, 2003

Most software with the new amd64 distros have a compiler (gcc)that takes advantage of the new arcitecture. Their has to be for these distributions to exist, without re-compiled code they would just be i686 still.

On this last post by TknD, i see what your saying, but dont forget that theirs 8 extra registers, and the fpu has another 8 simd.... whats the word?

c0d1f1ed · Sep 27, 2003

The main reason why a 64-bit OS is slower is because for every context swich, more than two times the data has to be stored/restored. And context switches are already one of the bottlenecks for any OS...

You can quickly make the sum: x86-32: 8 general-purpuse 32-bit registers + 8 MMX 64-bit registers + 8 SSE 128-bit registers = 224 bytes. x86-64: 16 general-purpose 64-bit registers + 16 MMX 64-bit registers + 16 SSE 128-bit registers = 512 bytes. So that's one kB per thread that has to be stored & restored per thread switch, which occurs a lot. And this all has to happen in slow system memory.

MajinChewY · Sep 27, 2003

Like you said the extra registers couldnt hurt, it would be a good indication of un optomised performance. Perhaps quake2 would be better since it could use the new 3dnow/sse registers in the fpu. Although im not shure if amd64 still supports 3dnow.

phsstpok · Sep 27, 2003

Of course.

OT:
How is a distribution built for a new platform?

It's been many years since I took a compiler course. IIRC, one way is to build a small cross-platform compiler. Use one machine to build an executable for the other machine.

Since 32-bit linux already exists and Athlon 64 can run 32-bit software in protected mode. Couldn't you just add a compiler that produces 64-bit code to a standard Linux distribution and then build your own 64-bit distribution by recompiling the sources?

56K, slow and steady does not win the race on internet!Edited by phsstpok on 09/27/03 02:54 PM.

MajinChewY · Sep 27, 2003

The linux kernal and many programs have been re-compiled to take advantage of the new CPU. Their is a true AMD-64 linux OS. C++ is a universal programling language to my knowledge, quake was programmed in C++. Ports have been made for SGI systems, alpha, sparc, ect, because linux has been ported to these oses, or the oses that run on these chips has a C++ compiler, most probably both.

All someone would have to do is get the correct libraries, and gcc the quake sorce. Since the compiler on x86-64 linux will compile a program as to be 64 bit code, the binary will be 64 bit. The x86-64 os will be able to handle the binary as well.

The benchmark will not show the full potential of the AMD-64 cpu, but it will be a good estimation of un optomised code. As far as games go. Quake2 would also be a good canidate, it supports SSE, and the new amd cpu has SSE registers in its FPU.
Edited by MajinChewY on 09/27/03 03:29 PM.

phsstpok · Sep 27, 2003

I think we'll see decent Linux benchmarks long before decent WindowsXP-64 benchmarks.

I'm sure optimizing OS code takes time. I just thought with a 64-bit (producing 64-bit code that is) compiler in place that you could simply recompile all the sources, quick and dirty. Maybe change a few declarations and macros first and then you have 64-bit Linux.

I guess it's not that simple?

56K, slow and steady does not win the race on internet!

addiarmadar · Sep 28, 2003

Never-the-less guys, it is too soon to be purchasing 64-bit CPUs in a world were 90% of sofware is still in 32bit interface. The 64bit CPU right now is only good for servers and not for gaming. Just Keep your OCed bartons and P4s for a couple of years till the software company makes 64-bit software from scratch.

F-DISK-Format-Reinstal DO DA!! DO DA!!

MajinChewY · Sep 28, 2003

O im waiting for dual channel ddr2, right now seems the time to buy a vid card.
Still, it would be interesting to see what we can expect from un optomised code, just something recompiled to use the extra registers.
Edited by MajinChewY on 09/27/03 09:20 PM.

AMD-64 Compiling Quake1

Distinguished

Guest

Guest

Distinguished

Splendid

Distinguished

Splendid

Distinguished

Splendid

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Splendid

Distinguished

Splendid

Distinguished

Distinguished

Share this page