Would K3 come out for Windows Vista?

[Det. Bart Lasiter]

^^^^

With programs written for 64-bit systems however, a programmer can pack more data into a single clock cycle by packing multiple numbers together, so for instance, the average packed size for 32-bit floating-point numbers is roughly 16 bits, so two numbers can be packed and processed in a single clock cycle. With a 64-bit system however, and the same packing size, one can fit 4 packed numbers into a single clock cycle, or 2 unpacked, 32-bit floats into a clock cycle.

 

In the case of games however, the above can hold true (though usually not for things that need to be processed quickly), but the extra precision can also increase frame rates as well, there's too many parts of the engine that this would hold true for me to mention here, but the results of 64-bit game performance speak for themselves.

 

That, plus the new 2 Gb sticks of RAM that are emerging, and AMD's new M2 socket will make sure that 64-bit systems will outperform 32-bit systems in the very near future.

 

 

Don't you realize it? The Athlon64 is the way better performer than the AthlonXP in a pure 32-Bit-environment... Do you really believe this has anything to do with it being 64-Bit instead of 32-Bit?

 

Actually, it does, the new AMD64 architecture is a superior performer, and, as it's 64-bit native, the A64's performance has been impacted by it being 64-bit (in addition to the memory controller, data paths, ect).

[Buzz1978]

With programs written for 64-bit systems however, a programmer can pack more data into a single clock cycle by packing multiple numbers together, so for instance, the average packed size for 32-bit floating-point numbers is roughly 16 bits, so two numbers can be packed and processed in a single clock cycle. With a 64-bit system however, and the same packing size, one can fit 4 packed numbers into a single clock cycle, or 2 unpacked, 32-bit floats into a clock cycle.

Wow, that sounds pretty obvious but raises a couple of questions. FP-variables are nonlinear quantized, how to you propose to pack them? Of course you can transfer more data over a wider bus but the width of the bus has nothing to do with 32 vs 64Bit, so what do you mean by process? Do you mean that a 64Bit-ALU can actually calculate two results if you feed it with two 32-Bit-inputs? (The FPU runs with highest possible precision anyhow but stops if the wanted precision is reached). And if it's so easy to speed up CPUs by simply making the ALUs and belonging registers bigger, why were we stuck with 32Bit for ~15 years?

 

but the extra precision can also increase frame rates as well, there's too many parts of the engine that this would hold true for me to mention here

Some illustrating examples are enough.

 

but the results of 64-bit game performance speak for themselves.

No, they don't because you're comparing two different architectures on two different OSs.

 

Actually, it does, the new AMD64 architecture is a superior performer, and, as it's 64-bit native, the A64's performance has been impacted by it being 64-bit (in addition to the memory controller, data paths, ect).

So you do actually believe that the A64 is faster in a 32-Bit-environment than the XP because it's 64-Bit? But you do know that in 32-Bit-mode the upper 32Bits of the "old" registers aren't available and the new registers aren't available at all that simply the OS doesn't even notice its talking 32Bit with a 64Bit-CPU?

[Char Ell]

FP-variables are nonlinear quantized, how to you propose to pack them? Of course you can transfer more data over a wider bus but the width of the bus has nothing to do with 32 vs 64Bit, so what do you mean by process? Do you mean that a 64Bit-ALU can actually calculate two results if you feed it with two 32-Bit-inputs? (The FPU runs with highest possible precision anyhow but stops if the wanted precision is reached). And if it's so easy to speed up CPUs by simply making the ALUs and belonging registers bigger, why were we stuck with 32Bit for ~15 years?

*** Hai Wan reads as BLAH, BLAH, BLAH-BLAH, BLAH ~15 years ***

 

It has become apparent to me that the technical level of this thread has exceeded my ability to understand. I do consider myself somewhat of a computer geek but I'm no CPU engineer. I know the difference between 32-bit and 64-bit but apparently I don't understand computer processor theory enough to know why a 64-bit CPU running at the same clock speed as a 32-bit CPU couldn't process 1 GB of data twice as fast as the 32-bit CPU if the data were fed to the CPU in the maximum data size the respective CPU's can handle. If anyone can explain in more simplistic terms I'll pay attention. But if not that's OK too. I'll add this to my list of topics that require my further research.

[Det. Bart Lasiter]

Wow, that sounds pretty obvious but raises a couple of questions. FP-variables are nonlinear quantized, how to you propose to pack them? Of course you can transfer more data over a wider bus but the width of the bus has nothing to do with 32 vs 64Bit, so what do you mean by process? Do you mean that a 64Bit-ALU can actually calculate two results if you feed it with two 32-Bit-inputs? (The FPU runs with highest possible precision anyhow but stops if the wanted precision is reached). And if it's so easy to speed up CPUs by simply making the ALUs and belonging registers bigger, why were we stuck with 32Bit for ~15 years?

This would mainly be used with resource files, if an engine can spend less time loading resources, it can use it's resources to render things faster. And fp's in resource files can be packed just like integers, in fact, that's exactly what BioWare did for the model animations of KotOR, although the method they unpacked them with decreased performance signifigantly... Also, we've been stuck with 32-but for ~15 years because an architecture that could perform well and be capable of 64-bit calculations wasn't around until AMD64. The bottom line is that 64-bit systems will outperform 32-bit systems once the technology can be fully taken advantage of.

 

Some illustrating examples are enough.

When dealing with large numbers that must be larger than what a 32-bit number can handle, a custom type has to be used that's usually packed, compressed, or defined as a typedef struct, and all of the afore-mentioned are much slower to unpack/uncompress/access that a simple

float fBlahBlah;

 

No, they don't because you're comparing two different architectures on two different OSs.

{snip}

So you do actually believe that the A64 is faster in a 32-Bit-environment than the XP because it's 64-Bit? But you do know that in 32-Bit-mode the upper 32Bits of the "old" registers aren't available and the new registers aren't available at all that simply the OS doesn't even notice its talking 32Bit with a 64Bit-CPU?

First off, the only difference between the OSs is the architecture, so if one performs better, it's obviously the architecture. As AMD64 was written as a 64-bit architecture, it was affected/influenced/impacted by it being 64-bit during the actual design of the architechture by AMD's engineers, although I do acknowledge that the actual hardware of the CPU makes a huge difference (i.e memory and clock speeds). As for this discusssion, I suggest we end it before this thread is closed

[Rain128]

One thing you also need to rember, K3 will also come out for the 360..

 

now im not 100% sure but a xp PC still out prefroms it no?? (im XboX dumb)

so we can talk about speed and such, but they will want to port it (lazy coders) and save as time as possable...

 

just my 2 creds

[Det. Bart Lasiter]

It depends on the specifications of the PC in terms of outperforming an XBox 360. As for 'lazy coders', you try writing a game engine

[Buzz1978]

First off, the only difference between the OSs is the architecture, so if one performs better, it's obviously the architecture. As AMD64 was written as a 64-bit architecture, it was affected/influenced/impacted by it being 64-bit during the actual design of the architechture by AMD's engineers, although I do acknowledge that the actual hardware of the CPU makes a huge difference (i.e memory and clock speeds).

Sorry, but you're wrong. The 32vs64 Bit thing between AthlonXP and Athon64 is a small difference. The big differences are all in the frontend and have nothing do with the backend being 64 Bit. Still the Athlon64 has new registers and enlarged "old" registers that can be split in smaller registers - these can only be used in 64Bit-Mode. That alone is sufficient to explain the higher performance on an 64Bit-OS reducing the need for time consuming memory accesses. But this has still nothing to do with the 32vs64 Bit difference.

 

EOD for me.