64 bit will have more cache misses because it will be using more registers.

its like saying you have a greater chance of getting a misfire in a V8 than a 4 cylinder engine. true. 2x as likely with 2x the amount of cylinders. but it doesnt mean the V8 is weaker.

doubling your cache actually decreases your amount of cache misses. having more cache means more data stored in cache, and the greater the likelyhood that a register finds its data in that cache.

the cache misses increase with register count. if register addresses double, from 5 to 10 bits, then you have 2x as many registers per bit increase. 5=32. 6=64. 7=128. etc. so the maximum POSSIBLE registers is immense. if you wish to maintain the same miss rate, you have to increase your cache size by the same % as you increased your register count. so 64 bit stands to have many more registers, and as a result much more misses. but these misses are caused only by the CPU _doing_more_, so there is still a performance benefit.

as for the addressing schaema i'm not sure what the new one is. the register count probably didnt go up linearly with a doubling of the system call format. if it did then there would be 1024 registers, and i dont think they would invest the $ into making that many. the immediate field probably increased at a higher proportion than the rest.

in any case, the code efficiency increase will offset the 10 or so cycles wasted on a miss every so often. if it werent faster, there would be no point in making the change. accuracy is only so important, since when you have to be super accurate, you use BCD methods anyways, and they work on any system and offer (as good as) infinite accuracy.

-scheherazade

This comment was edited on Nov 27, 19:06.

Don't be silly. After all, we all know no-one needs more than 640k of memory.

Was it 640k that Gates quoted all that time ago? D'oh!

Don't get too excited about 64-bit yet. Its far from guaranteed than it will run faster than 32-bit. In fact its mostly my experience that currently 32-bit applications run faster (8 - 9% is common) since cache misses are so expensive but it very much depends on the application.

If you double the cache you will still have double the cache misses of 32 bit.

However imagine the day when you have 8G of RAM in your PC and imagine what games will be able to do with that!

What does one do when they dont undertand something? Get mad and defensive. Needles dont take out on others cause your mom decides to marry her brother. Not every one has the knowledge to understand basic pc hardware. LOL and in advance, if your gonna dish it out learn how to take it.

LOL ok dork most of us get the idea and the ones who dont, like your explaination is going to make it easier to understand. Plain and simple it's like the Horsepower 64hp is better the 34hp. Or like a sewer pipe you can get alot more crap through a 64cm pipe the a 32cm pipe. You dont need to get all geeky explaining 64 is better the 32.

"Who cares, I mean I know that 64 bit will be much nicer, but I will probably end up running the game 32-bit on those processors, just like I run the game 16-bit on my 32-bit now"

ow..... oh owwwww!! oh oh owwwwwwwww. stop, you are hurting me. ayayayayay

This comment was edited on Nov 26, 17:35.

sweet jeebus!

We are not talking about the colour depth!
we ARE talking about the underlying system!

Who cares, I mean I know that 64 bit will be much nicer, but I will probably end up running the game 32-bit on those processors, just like I run the game 16-bit on my 32-bit now;
Reason for this is for smoother gameplay, to keep me OWNING all of you newbies at MY game.


FrantiK

yeah, what he said.

you guys are missing something...

register address calls are 5 bit in 32 bit systems.

31-26 25-21 20-16 15-0

31-26 = opcode
25-21 = register
20-16 = register
15-0 = immediate ||+ target register

that means that you have 2^5 registers max. thats only 32 registers.

some of those go away for the OS, some are FP registers, some are FnCall registers, some are return registers, etc. so the registers software can actually work with is smaller than 32.

when you go 64 bit, you expand the max register count.
along with this, the actual register count goes up too (though not necissarilly as far as it can at most.

so when software goes through its code in the CPU. it is fetched and unrolled so that it can fill the pipeline.

for example, this code swaps 2 arrays of length 100

(a0) = address of array 1
(a1) = address of array 2
t0 - t2 = temporary registers

add t0 <- zero, 100 // sets reg. t0 to 100

lw t1 <- (a0)
lw t2 <- (a1)
sw t1 -> (a1)
sw t2 -> (a0)
add a0 <- a0, 4
add a0 <- a1, 4
sub t0 <- t0, 1
beq t0, zero -> done



the CPU unrolls the loop and executes it 2 at a time, using MORE REGISTERS, but ending up using LESS instructions.

(a0) = address of array 1
(a1) = address of array 2
t0 - t4 = temporary registers, 2 more than before

add t0 <- zero, 100 // sets reg. t0 to 100

lw t1 <- (a0)
lw t2 <- (a1)
sw t1 -> (a1)
sw t2 -> (a0)

lw t3 <- 4(a0)
lw t4 <- 4(a1)
sw t3 -> 4(a1)
sw t4 -> 4(a0)

add a0 <- a0, 8
add a0 <- a1, 8
sub t0 <- t0, 2
beq t0, zero -> done

-------

the first loop will go 100 times
the second loop will go 50 times

the first will execute 8 commands per pass
the second will execute 12 commands per pass

100 * 8 = 800 commands
50 * 12 = 600 commands

600 < 800

so the second loop that uses MORE registers, will execute in less time. meaning its FASTER.

now this example is simplified, but in this nature, more registers can be used to speed up calculation.

so a 64 bit cpu, having more registers than a 32 bit cpu, will execute its code in less time, because it has more resources to work with. there will be more robust code with more parallelism in execution, and less 're-writing temp data to main memory' to fit more temp data that is needed.

this means that when you compile a program in 32 bit, or 64 bit, the compiler generates DIFFERENT ASSEMBLY CODE for both. the 64 bit assembly code will nearly always be faster than the 32 bit, and in turn, the resulting set of machine instructions for 64 bit will turn up faster than the 32 bit instructions.

even though the C++ code may be the same, the REAL code that the CPU reads will be very different.

so when UT2003 is compiled for 64 bit, its code is faster than before (32 bit).

THOUGH for identical code, the 64 bit could be slower. the issue is, though, the code will not be identical. thats the benefit of wider systems. (that and more accuracy in data)

sure cache may need to be bigger, but it'll just be bigger. problem solved. even if it didnt increase, things would still be faster.

-scheherazade

This comment was edited on Nov 21, 18:37.

Might I suggest you look up the word "tact" before posting in the future. There's nothing wrong with disagreeing with someone, but it needn't sink to personal attacks especially when they are unwarranted.

Needles - not only aggressive, but stupid to boot. What a wonderful combination. Meatpole was absulutely correct in what he said.

It is not possible to run a 64-bit OS on a 32-bit CPU unless it's a 32-bit CPU with 64-bit extension like the Athlon 64. BTW, the 64-bit version of Windows XP does not work on the Athlon 64 but is for Itaniums only...

Meatpole, you are dead on right with your 64-bit performance assumption of UT2003. It indeed will run a little slower unless you have a very powerful 64-bit CPU which the Athlon 64 surely isn't. Mark Rein himself stated in an interview months ago that there won't be any speed increase when using the 64-bit version of UT2003. It's rather just a gimmick

Isn't that something of a pointless statement? It's like saying a 42-ton truck chassis has very lacklustre performance using a 1.4-litre Honda Civic engine...

I didn't even know it was possible to run 64-bit Windows on a 32-bit machine, but certainly wouldn't consider it to be in any way sane or sensible

Just FYI...

the 64 bit versions of Win2K Svr and Advance Svr are very lackluster in performance unless you are running on a 64bit processor.

oi! here it is, off the eWeek site:

http://www.eweek.com/article2/0,3959,716687,00.asp

just read an article today on the itanium and how it'll have a seperate area on the chip for 32 bit emulation, i.e., backward compatibility for the x86 world...

if i can find the article again i'll post it here.

yes, Microsoft has (or will have) a 64-bit version of Windows

http://www.microsoft.com/windowsxp/64bit/default.asp

Schnapple

http://members.tripod.com/schnapple99/

Do any versions of WinXP have native 64bit support? Are there any 64bit OS's? If not, will there be?

Slow down there, meatpole. You have no knowledge of how much cache the processor will have - it could easily have twice as much.

Also, since they're releasing a 64 bit fix, you could bet the code is optimized for 8-byte pointers.

One more thing - they tout backward compatibility, so I would bet 4-byte pointers still work just fine. My guess is that the chip can just ignore the upper half of its adress space (or applications can, at least).