vista 32 or 64 bit?

Inquirer are hinting Nvidia is concentrating on the 32bit Vista driver 1st :(

http://www.theinquirer.net/default.aspx?article=36739

But its inquirer so could mean anything...

Id still go 64bit purely cos its more future proof and 4gig I will get for Vista afterall its gonna last for a long time. Seems petty for 32bit really since all the latest cpus thats been out for 2-3 years are 64bit from both intel/AMD.
 
To be honest, except the extra memory addressing what does 64bit bring to the table? It's not going to be faster is it.
 
PiKe said:
To be honest, except the extra memory addressing what does 64bit bring to the table? It's not going to be faster is it.

It costs the same, so even if it's something small like the extra memory addressing, it's better than nothing.
 
PiKe said:
To be honest, except the extra memory addressing what does 64bit bring to the table? It's not going to be faster is it.


It's a good point and something that the software dev fraternity should explain to us all.

How will 64bit computing make our apps (or games ;)) faster?
 
PiKe said:
To be honest, except the extra memory addressing what does 64bit bring to the table? It's not going to be faster is it.


I read this at Paul Thurrott's SuperSite for Windows.

"x64-specific features

A number of Windows Vista security features will only be made available on x64 versions of the OS, the 64-bit versions of Windows Vista that run on newer AMD and Intel processors. These include Kernel Patch Protection (sometimes called PatchGuard), which prevents hackers (and as it turns out, security companies and even Microsoft applications) from altering the Vista kernel at run-time; digitally signed drivers, which ensures that all hardware drivers used in x64 Vista versions are digitally signed and therefore of high quality and unlikely to be the cause of instability issues; and the removal of the 16-bit subsystem, which breaks compatibility with older applications but makes the overall system simpler and more reliable."
 
testa12 said:
It's a good point and something that the software dev fraternity should explain to us all.

How will 64bit computing make our apps (or games ;)) faster?
Because when a 32-bit application needs to do a 64-bit calculation it must use two 32-bit words and then combine them. This is slow. On a 64-bit environment it can just do the calculation like any other and it is very fast.

Games are increasingly wanting to use high range data types (such as 64-bit integers) for their complex physics and even game logic calculations.

x64 variants of Windows are also faster in other ways (such as thread context switching) which I've already explained in this thread.

PiKe said:
To be honest, except the extra memory addressing what does 64bit bring to the table? It's not going to be faster is it.
It brings much better security over and above what Vista x32 has. Performance is improved also, but most of the potential gain is waiting to be tapped by newer 64-bit compiled software.

The extra memory is the main selling point. It won't be long until many OCUK'ers won't even consider building a system with less than 4GB of memory.

Paul Thurrott said:
and the removal of the 16-bit subsystem, which breaks compatibility with older applications but makes the overall system simpler and more reliable
I used to have quite a bit of respect for this man. But damn you can see he's clutching at straws here. A "simpler" system... right, and who exactly does that benefit except the developers at Microsoft? A more "reliable" system? That's just tosh as well. 16-bit being present in NT has never caused any issues in this regard.
 
Last edited:
Another questions guys.

I read that Vista supports up to 4 GB under the 32 bit editions.

But does anyone know if under Vista you will finally be able to allocate the
whole 4 GB yourself (applications)?
Or is this still limited to 3 GB for applications and 1 GB to Kernel?
 
What are examples of 16-bit applications? Programs that used to run in the DOS prompt?

I've got some games that are really old, I don't want x64 to break them... :eek:
 
Right now, there isnt all that much 64bit apps that take advantage, but now Vista is here, there will be... Masses of the stuff too!

What you go to do is look atthings logically and ask yourself whats best?

Shall I get 50% of my stuff to run now, and get up to 75% by next year...

or

Shall I get 45% of my stuff running now, and have 100% of it by next year

Bit of a silly semi-chart there but thats how its going to be...

32Bit Support is going to be dropped, thats a given.

64Bit is going to carry on, and eventually take over 32Bit

32Bit CPUs are not really made anymore are they? Sure there are some Intels still around, but with no 32Bit CPUs there will be no 32Bit OS either, and Vista will go the way of all the others in the past, 64Bit will carry onand where will that leave you then?

Needing to buy another licence for 64Bit support, thats where!

On the 4GB Side of things, this is very true, and you must remember one thing thats often over-looked...

XP can only support 4GB total... Thats REAL RAM + VIRTUAL RAM

With apps getting bigger and bigger all the time, its not going to be alll that long before all games need 64Bit... With games such as FarCry showing the fairly big difference between 32 and 64 Bits, gamers will find themselves stuck in the dark ages of poor 32Bit
 
aj_4176 said:
Another questions guys.

I read that Vista supports up to 4 GB under the 32 bit editions.

But does anyone know if under Vista you will finally be able to allocate the
whole 4 GB yourself (applications)?
Or is this still limited to 3 GB for applications and 1 GB to Kernel?
XP is limited to 4GB because it's 32-bit - correct.

XP splits a running process' virtual memory space in two halfs - 2GB for user mode and 2GB for kernel mode. This limit is never reached on a desktop PC doing even the most demanding of desktop/multimedia/gaming tasks.

On x64 variants of Windows, each running process has access to a full virtual memory address space of 128GB. The split between user and kernel mode is dynamic.

FatRakoon said:
Thats REAL RAM + VIRTUAL RAM
This doesn't really make sense. Virtual memory isn't an "overflow carpark" (for lack of a better metaphor) - it is just a mapping table of a full memory address space (e.g. 4GB for 32-bit or 128GB for 64-bit). It is broken down at a granularity of 4KB - these are called "pages" of memory. It contains a pointer for each page, the pointer will point to either a location in RAM or in the page file.
 
Last edited:
Quick question for NathanE (you're in demand tonight!!! :) )

Is there any disadvantage in terms of the actual processor when running in x64 mode. I know you mentioned the software benfits above, I was just wondering if there was any inherant advantages or optimisations to the procs for when running 32bit code.

Not made myself very clear I don't think, but for example (and this is pure fiction)

"C2D and AMD x64 procs SSE and 3DNow functions are optimised/hard coded for 32 bit operations and so in some situations a proc running in 64bit mode could end up not being so effective."

I've completely made that up and I could be talking complete twaddle and demonstrating my ignorance of stuff at this level.

Just wondering if there is a downside with current gen hardware that's all.
 
stoofa said:
Intel still had the better way of dealing with the move from 32bit to 64bit but again they were held up by software houses refusing to play ball.
16bit to 32bit was a pretty minor update and doing things in two stages - 32bit with 16bit emulation and then 32bit was the correct way forward.
However we would be far better off having a true 64bit CPU now rather than something that is a hybrid.

Intel usually win these battles and rightly so - because without the likes of Intel forcing things forward the software houses certainly wouldn't advance anything.

Intel's and AMD's current solutions are extremely similar - however to say Intel simply copied AMD, refuse to give credit etc is not really true.
Both Intel and AMD's solutions are based on open specifications.
Sure both Intel and AMD have their own proprietry way of doing some aspects which are compatible with one another - but certainly not just a direct copy and claim it is their own technology.

Intel had the better idea, they couldn't get the software houses on board so were forced to back track slightly.
Think where we could be now if we were using true 64bit CPU's that didn't require any 32bit emulation.
This is where we could be right now if AMD had been brave enough to follow Intel's lead with regards 64bit implimentation.


Er no, ya best read up on what did happen, AMDs design is very good, intels 64bit design was and is flawed in MANY areas, infact I dont think iv seen such a bad design of a cpu since the cyrix days, IA64 running its native software in 64bit mode is a lot worse than it should be
 
Athanor said:
Quick question for NathanE (you're in demand tonight!!! :) )

Is there any disadvantage in terms of the actual processor when running in x64 mode. I know you mentioned the software benfits above, I was just wondering if there was any inherant advantages or optimisations to the procs for when running 32bit code.

Not made myself very clear I don't think, but for example (and this is pure fiction)

"C2D and AMD x64 procs SSE and 3DNow functions are optimised/hard coded for 32 bit operations and so in some situations a proc running in 64bit mode could end up not being so effective."

I've completely made that up and I could be talking complete twaddle and demonstrating my ignorance of stuff at this level.

Just wondering if there is a downside with current gen hardware that's all.
When running in long mode (64-bit mode) the Athlon 64's will execute 32-bit code at an identical speed to what they would if they were running in 32-bit mode.

The same applies to Pentium 4's with EM64T.

Core 2 Duo ("Conroe") has a slight difference. There is an optimisation that Intel did to this architecture that only works in 32-bit mode. They call this "macro-ops fusion" - it is basically some logic on the chip that identifies a group of related instructions and compresses them into a single instruction that then sits on the pipeline requiring less space in the pipeline - very cool. However they only implemented this logic for 32-bit mode and unfortunately it gets turned off when any 64-bit OS loads up. As a result, 32-bit code executing on a Conroe chip whilst running a 64-bit OS will possibly run a couple percent slower than it traditionally would. I think Intel just ran out of time and wanted to tape-out Conroe ASAP (they were sweating buckets back then). I would expect to see this macro-ops fusion enhanced on their next chip to support EM64T fully.
 
Combat squirrel said:
Er no, ya best read up on what did happen, AMDs design is very good, intels 64bit design was and is flawed in MANY areas, infact I dont think iv seen such a bad design of a cpu since the cyrix days, IA64 running its native software in 64bit mode is a lot worse than it should be
IA-64 is not flawed. Their plan on bringing it to market was however. IA-64 is possibly the most elegant and scalable 64-bit instruction set, ever.

AMD64 is crap, utter utter crap, as far as 64-bit instruction sets go. AMD's plan to bring it to market was well thought out (extend x86 and maintain backward compat.) and ultimately that's what won them Microsoft's support.
 
Last edited:
Back
Top Bottom