On 10/21/05, Rudolf Kastl <che666@xxxxxxxxx> wrote: > 2005/10/21, Rudolf Kastl <che666@xxxxxxxxx>: > > 2005/10/21, Rudolf Kastl <che666@xxxxxxxxx>: > > > the faq gives the answer to the question if we should email id soft > > > about that... > > > they know that theres x86_64 linux. Okay. > > > its not just about compiling... in theory you only compile source code > > > and it works on 64 bit... practically... it needs code changes in this > > > case to work properly. Of course any assembly code would need to be recoded. But C/C++ code just needs to be recompiled. The compiler will optimize the code and make use of the 64-bit hardware. > > > why it would be slower? id recommend to discuss that on > > > irc.freenode.org on the iccuslus channel or #etpro. both channels have > > > people that actually really worked on the q3 engine e.g. as far as the > > > et port goes. > > > > > > theres an x86_64 port of q3 btw... the people who ported it might be > > > on irc even and there has been actually alot discussion on the topic > > > there. > > > > > > Talking about doom3 and if it would be slower or not wouldnt make > > > sense at all... we both dont have the source code of doom3 do we? ;) No, but I do know the architectural changes in x86_64, and it has features, such as 16 GPRs, that should help accelerate code execution. More registers means less stack usage which means less memory traffic. Memory is slow, registers are *fast*. > > > regards, > > > Rudolf Kastl [snip] > > > > > > sorry for the typo... its the icculus channel ;) > > > > http://www.nvnews.net/vbulletin/archive/index.php/t-4578.html > > this thread contains links to an interview with john carmack that > states that 64 bit boxes will run doom3 slower. atleast a statement > from someone that knows the code. He may know the code, but does (or did) he know what 64-bit means? Besides, that thread is from 2002. AMD64 wasn't even out then, was it? His statement doesn't even make sense: "64 bit is not going to speed up Doom 3. In fact there may actually be a minor slowdown since the pointer references are all in 32 bit, which will mean a hit to memory bandwidth which is the real gating problem." What does "pointer references are all in 32-bit" mean? You can address more virtual memory in 64-bit, which usually means that memory intensive programs do better. Perhaps he is talking about running the 32-bit game in a 64-bit OS, which is not what we are talking about. We're talking about building the game as a 64-bit executable, to fully take advantage of the processor. > umm... yeah some things can be faster... i dont doubt that... real > measurement and statistics though are necassery for a real comparison. That would help. This discussion would be pointless if that were possible, though :). > last time i checked some performance analysis the nvidia drivers for > 64 bit been slower too. If 64-bit code is not faster than 32-bit code, then why are AMD, Intel, and Microsoft putting so much effort into producing 64-bit processors/software? Yes, there are other benefits than speed, like terabytes of virtual address space. Sure there will be some code where the extra registers will not help and maybe you get extra cache misses because of some 64-bit data or something, but you could see those types of effects between different processors with the same ISA (eg Intel vs AMD, or Thoroughbred vs Barton cores). > doom3 could maybe be faster if it was rewritten ;) Again, yes, assembly must be rewritten. C/C++ just needs recompilation (unless there is sloppy code, like making ints from pointers). The compiler takes care of the optimizations. > regards, > Rudolf Kastl > > p.s. still think thats a ridiculous statement? For the most part, yes. It could depend on what exactly we both mean. I'm saying that it is rediculous to think that a properly ported Doom 3 will perform worse as a 64-bit executable than a 32-bit one. How much work that entails, I do not know. But software companies better get used to 64-bit, 'cause it's here to stay. Jonathan
