is there going to be that much of a difference running an amd64 on 64 bit win as opposed to 32bit?
when microsoft releases the 64bit windows......
- Thread starter hugekebab
- Start date
Depends on what you do...
Most of the time the computer sits and waits for the users to do something anyway. Day to day tasks are limited by the access time of the hard drive and the speed of your internet access.
For large rendering jobs, FEA, compiling, and heavy duty apps (assuming aforementioed are 64-bit optimized), you'll likely see a marginal improvement.
Most of the time the computer sits and waits for the users to do something anyway. Day to day tasks are limited by the access time of the hard drive and the speed of your internet access.
For large rendering jobs, FEA, compiling, and heavy duty apps (assuming aforementioed are 64-bit optimized), you'll likely see a marginal improvement.
Thats still a big unknown, drivers are not properly optimised and there are no 64-bit games yet to test.
Well, wouldn't 32 bit games running in a 64 bit system get a performance boost? Or shouldn't they at least...
true... i read an interesting article the other day (forget where, sorry!) about the future of 64-bit gaming and apparently a lot of software companies are really excited about the idea because although it might not necessarily translate to gigantic performance increases, they will be able to do a lot more stuff like have more realistic textures, lighting, environments etc... in fact iirc we can expect a couple 64bit-optmized titles by as early as next year...
gsellis
Diamond Member
- Dec 4, 2003
- 6,061
- 0
- 0
Remember that right out of the box, Win32 apps run in a Windows On Windows emulation similar to NTVDM and Wow associated with 16-bit Windows apps. The system has to thunk all of the 32-bit address stuff to 64-bit. So, there is another layer/shim required for 32-bit apps. 32-bit games may not be all that much faster and could potentially be slower.
blurredvision
Lifer
- Oct 19, 2000
- 17,860
- 4
- 81
When is the 64-bit Windows OS scheduled to release anyhow? I haven't heard anything for a while now.
There are are few 64 bit games,but only a few.
Shadow ops comes to mind & i think Far cry has a 64 bit version too if i'm not mistaken.
Regs
Lifer
- Aug 9, 2002
- 16,665
- 21
- 81
I remember hearing about a 64 bit unreal tournament too. I don't know if they made it and just haven't released it because 64-bit is a long way from being a completed spec.
64 bit could be useful since games that are programmed for it can take use of the CPU's extra internal registers. This gives the CPU more of a window to calculate. I haven't heard much about how 64 bit will work for games in months. So that little bit of information I know could just be a myth. The theories about 64 bit gaming performance are being washed out by the impending dual cores and the mutli-threaded games which sound a lot more promising right now for the immediate future than 64 bit.
64 bit could be useful since games that are programmed for it can take use of the CPU's extra internal registers. This gives the CPU more of a window to calculate. I haven't heard much about how 64 bit will work for games in months. So that little bit of information I know could just be a myth. The theories about 64 bit gaming performance are being washed out by the impending dual cores and the mutli-threaded games which sound a lot more promising right now for the immediate future than 64 bit.
While there are some benefits of 64-bit code, 64-bit data and pointers are also twice as big as 32-bit instructions which has the effect reducing the amount of speculative prefetches you do and effectively halves the usefulness of a given cache size. Some apps will speed up but some slow down too.
I doubt that 64 bit will make a big difference in gaming. Most of the floating point calculations are done in the GPU anymore (64 bit registers mainly speed up large floating point calculations) and the AI and physics are handled in CPU. As games get more complex and require over 2 gigs of ram to run, 64 bit will be necessary since the current limitation created by 32 bit addressing is 2gb usable ram per running thread.
In reality 64 bit being any faster than 32 bit is kind of a dillusion people have of how CPU technology works. A lot of these benchmarks use datasets larger than 2gb in size which is where 64bit cpu with 64bit software can handle this task better. For encoding, 64 bit will have a minimal benifit as technology like SSE2/3 and 3dnowPRO are mainly used for these functions (and are still more efficient for encoding algorythms than even 64 bit CPU instructions)
In reality 64 bit being any faster than 32 bit is kind of a dillusion people have of how CPU technology works. A lot of these benchmarks use datasets larger than 2gb in size which is where 64bit cpu with 64bit software can handle this task better. For encoding, 64 bit will have a minimal benifit as technology like SSE2/3 and 3dnowPRO are mainly used for these functions (and are still more efficient for encoding algorythms than even 64 bit CPU instructions)
64-bit GP registers speed up floating point calculations? Why would the register size of GP registers affect FP operations? FP registers have been 80 bits for a long time (386?).
OTOH, at least on amd64, you have twice as many registers for your program to use (and even if the program is running in 32-bit mode, a 64-bit OS can use the other registers to avoid having to displace program data as often, at least theoretically).
And isn't the effective cache size *already* halved, or does the Athlon64 have the capability to access the cache in 32-bit pieces in its native 32-bit-only mode?
biostud
Lifer
- Feb 27, 2003
- 19,731
- 6,808
- 136
I'm not denying that there are benefits. I'm just saying that it's not all good news and there are many reasons (I can list a few more too) why performance can go down - in some cases by a significant amount when there are a lot of pointers involved.
I honestly don't know. I don't know much about the microarchitectural implementation of the Athlon 64. But I would be very surprised if it couldn't - how else would it work? Pad the rest of the it?
Hey, I agree. I just wanted to point out that it's not all bad, either.
Well, yeah.
The simplest cache hardware implementation (I would think) would be to load and store the whole 64-bit register all the time, and then in 32-bit mode the CPU simply ignores the upper 32 bits.I was thinking that having the capability to split the cache like this would be a huge PITA (and it probably is), but it could be done. You'd have to essentially have cache logic that could switch from 32-bit to 64-bit mode as well, and data/address lines that could be split in half and multiplexed to different registers simultaneously, wouldn't you? I would think that would slow it down a *lot*, but maybe there's more logic already between the registers and cache than I'm taking into account, and it wouldn't hurt it that much to add another layer of indirection.
Originally posted by: Matthias99
Well, yeah.
I was thinking that having the capability to split the cache like this would be a huge PITA (and it probably is), but it could be done. You'd have to essentially have cache logic that could switch from 32-bit to 64-bit mode as well, and data/address lines that could be split in half and multiplexed to different registers simultaneously, wouldn't you? I would think that would slow it down a *lot*, but maybe there's more logic already between the registers and cache than I'm taking into account, and it wouldn't hurt it that much to add another layer of indirection.
In general, designing a CPU is a horrendous PITA.
I can only speak to caches that I have worked on the design of; I haven't spent a lot of time looking at how everyone is doing it nowadays - but those guys at AMD definitely know what they are doing and I'm sure that they didn't pad out the lines. The way that I did it when I worked on the load and store buffers for a cache was to read out the entire cache line for a read, and then steer the "critical chunk" - whatever size that chunk needed to be - to the output. So, using fake numbers (as much as anything because I can't remember what the real numbers were), I'd read out 256 bits (not counting ECC) and then knowing specifically what part of the line that I wanted, I'd mux out the 64-bits that I wanted and send that off. If we had smaller quantities that we'd need - 16-bits, 32-bits, I swazzle those smaller bits up too down to a resolution of 8-bits.
Originally posted by: pm
Originally posted by: Matthias99
Well, yeah.
I was thinking that having the capability to split the cache like this would be a huge PITA (and it probably is), but it could be done. You'd have to essentially have cache logic that could switch from 32-bit to 64-bit mode as well, and data/address lines that could be split in half and multiplexed to different registers simultaneously, wouldn't you? I would think that would slow it down a *lot*, but maybe there's more logic already between the registers and cache than I'm taking into account, and it wouldn't hurt it that much to add another layer of indirection.
In general, designing a CPU is a horrendous PITA.
I can only speak to caches that I have worked on the design of. The way that I did it when I worked on the load and store buffers was to read out the entire cache line for a read, and then steer the "critical chunk" - whatever size that chunk needed to be - to the output. So, using fake numbers (as much as anything because I can't remember what the real numbers were), I'd read out 256 bits (not counting ECC) and then knowing specifically what part of the line that I wanted, I'd mux out the 64-bits that I wanted and send that off. If we had smaller quantities that we'd need - 16-bits, 32-bits, I swazzle those smaller bits up too down to a resolution of 8-bits.
Ah, OK. I was thinking the natural thing would be to build in cache lines that were 64 bits wide, but if they're already using wider ones, they would need this kind of logic anyway. That makes sense.
I found our ISSCC paper on the implemention of the one that I worked on:
http://www.intel.com/design/itanium2/download/isscc_2002_3s.pdf
Page 18 mentions it briefly.
Using the real numbers, now the L1 pulled in 64-bit chunks and then we could mux down to 8-bits. We needed to move the bits around for endianess too.
It was quite the mux circuit. I called it "The Swizzler" because we started calling all this mux and swapping "swizzling". Made people smile during presentations.TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter