Are 64 bits really faster than 32?

[ModestGamer]

I have heard that 64 bit architecture does not outperform 32 bit because 32-bit applications do not take advantage of the oversized processors since they run under a backward compatibility mode. To take advantage of the 64-bit the old 32-bit apps should be rewritten or at least recompiled.

In other words, buying a 64-bit laptop, configured with Win 7-64, is just a waste of money if I don't buy 64-bit apps. Is that true?

In computing, word is a term for the natural unit of data used by a particular computer design. A word is simply a fixed sized group of bits that are handled together by the system. The number of bits in a word (the word size or word length) is an important characteristic of computer architecture.
The size of a word is reflected in many aspects of a computer's structure and operation; the majority of the registers in the computer are usually word sized and the amount of data transferred between the processing part computer and the memory system, in a single operation, is most often a word. The largest possible address size, used to designate a location in memory, is typically a hardware word (in other words, the full sized natural word of the processor, as opposed to any other definition used on the platform).
Modern computers usually have a word size of 16, 32 or 64 bits but many other sizes have been used, including 8, 9, 12, 18, 24, 36, 39, 40, 48 and 60 bits. The slab is an example of a system with an earlier word size. Several of the earliest computers used the decimal base rather than binary, typically having a word size of 10 or 12 decimal digits and some early computers had no fixed word length at all.
The size of a word is sometimes defined to be a particular value for compatibility with earlier computers. The most common microprocessors used in personal computers (for instance, the Intel Pentiums and AMD Athlons) are an example of this; their IA-32 architecture is an extension of the original Intel 8086 design which had a word size of 16 bits. The IA-32 processors still support 8086 (x86) programs, so the meaning of word in the IA-32 context was kept the same, and is still said to be 16 bits despite the fact that they at times (especially when the default operand size is 32 bits) operate largely like a machine with a 32 bit word size, similarly in the newer x86-64 architecture a word is still 16 bits, although 64-bit (quadruple word) operands may be more common.
Now this only matters if you have a CPU that can exectue a 64bit instruction as fast as a 32 bit instruction. IE it can execute more commans per word. this can improve computer effieicny.

http://en.wikipedia.org/wiki/Word_(computing)


You also get high floating points and more adress space. there are a whole host of differences.

The big issue again is Poor OS implementation and more crappy code not taking advantage of these features often enough.

To answer you ruqestion. Properly coded software using certain instruction groups can infact be faster then 32b or 16b etc etc etc adnueseum. It just depends on the CPU pipeline and execution design.

 

[PavkaGuru]

Sorry guys. I can't follow your drift. I'm not able to re-compile nor re-link the app. I just own the executable (.EXE) objects, along with the runtime libraries. If I had the .OBJ objects and the required libraries, I could relink the app. I asked the vendors if they could. The answer was NO, since they don't longer support the version I own. Instead they offered me their latest, state of the art, leading edge 64-bit version, for mere 32,000 bucks. Not more nor less. It sounded me like a daylight robbery.

Anyway, I'm going to upgrade to 64-bits, install the app, and see if its performance improves. Hopefully it will.

Thank you, mates

Pavka Guru

 

[mv2devnull]

You could also take the liberty to assume that a $15000 engineering application could possibly run something other than Windows - PAE support on Windows is extremely anemic without some (rather trivial, but still) Kernel hacks.. just to add that as well

That raises a followup thought:
Are/were there "old" (database) applications, which are addressing huge data on a "pathetic" OS?

While a single process cannot address more memory simultaneously than it can, it can work around by hashing addresses itself, caching to file(s), or by spawning sibling processes and resorting to interprocess communication. All those are naturally crude hacks and slow compared to having single memory address space. (Myself being *nix user I've never had address problems, except in Windows, where each DLL appears to own its private memory space.)


Anyway, PavkaGuru, if your current machine swaps because both the application and the OS do not fit into the physical memory simultaneously, then the larger 64-bit memory will help.

If the application "cleverly" uses more than expected (by some hook or crook), then more memory will still help.

 

[Scali]

except in Windows, where each DLL appears to own its private memory space

Nope.
A DLL is mapped into the address space of the process that loads the DLL.
So all DLLs loaded by a process share the same address space.
When a DLL is loaded into more than one process, the same physical memory is remapped into the new address space, so memory is shared/conserved. The exception is with writable memory areas, which are generally copy-on-write.

 

[Scali]

You could also take the liberty to assume that a $15000 engineering application could possibly run something other than Windows - PAE support on Windows is extremely anemic without some (rather trivial, but still) Kernel hacks.. just to add that as well

That only goes for the consumer/desktop versions of Windows.
The server versions (which you should be using for any server/workstation, especially ones that run $15000 engineering apps) will allow you to use more memory through PAE.

There's a solid reason why PAE is limited on the regular XP/Vista/7 flavours though: A large number of drivers cannot handle an address space > 4 GB properly.
This is also why quite a few drivers will not work under a server version of the OS, even if they share the same generation of kernel.
Microsoft figured it would be okay to have more stringent requirements for driver compatibility for the server version. Most troubled drivers are not for server hardware, but for cheap consumer toys, like webcams, sound cards, and that sort of nonsense that you'd never use on a server (or workstation) anyway.
So a driver for a server version MUST work correctly with PAE and a > 4 GB address space.

 

[Borealis7]

i know winrar works faster with 64bit.

my knowledge is a bit dated but as i remember it from college, also it depends on how Intel/AMD program their instructions to use the extra instruction word space. here's a basic example from "intro to EE" course:

imagine an instruction MSK that applies a "1010..." mask to a 32bit word (integer basically)

X <- MSK32 (some 32bit number)


in 32bit CPUs you would need to
1) prepare the mask (add 1, shift left twice,repeat 15 times) = ~45 steps
2) store the mask in the B operand register
3) load your number to the A operand register
4) MUL between the operands.
5) store the result in X

in 64bit:

X <- MSK64 (some 32bit number)1010101010...


as you call the MSK instruction, you use the first 32 bits of your number for the number itself, and fill bits 32..63 with "101010..." so there is no need for step 1.
you've just save a bunch-load of steps and your instruction is faster! yey!

*disclaimer: the author is not an electrical engineer, and he is aware that the OP# itself takes space in the instruction word and so on and so forth.

 

[Schmide]

Nope.
A DLL is mapped into the address space of the process that loads the DLL.
So all DLLs loaded by a process share the same address space.
When a DLL is loaded into more than one process, the same physical memory is remapped into the new address space, so memory is shared/conserved. The exception is with writable memory areas, which are generally copy-on-write.

Yes a DLL is mapped into the address space and does look like it's part of the contiguous space, but it still has its own unique descriptor tables and thusly may or may not follow the same rules as the exe's space.

I think what mv2devnull is referring to is the local page management each DLL windows NT+ has (ME/98 and the like didn't have it). For example if you allocate a chunk of memory in one DLL and attempt to free it in another you will more than likely receive a protection fault.

 

[Cerb]

Anyway, I'm going to upgrade to 64-bits, install the app, and see if its performance improves. Hopefully it will.

If not, maybe consider getting a [sacrificial] SSD, for your page file, to help a bit.

 

[mv2devnull]

I think what mv2devnull is referring to is the local page management each DLL windows NT+ has (ME/98 and the like didn't have it). For example if you allocate a chunk of memory in one DLL and attempt to free it in another you will more than likely receive a protection fault.

Yes, that is it. Whatever it is called, it was an unexpected and painful wall of bricks to stumble to on "simple" port of "simple" application.

 

[Scali]

Yes, that is it. Whatever it is called, it was an unexpected and painful wall of bricks to stumble to on "simple" port of "simple" application.

The answer is the same as what you get for most *nix problems though: RTFM

I always have to laugh when these self-proclaimed *nix users complain about problems with Windows. It's *never* their fault, despite the glaring ignorance of the system.

 

[fuzzymath10]

At 4GB, also note that you're enabling the full accessibility of the memory which sort of offsets the higher memory requirements.

Any x64 capable machine I have with at least 2GB memory has x64 Windows.

If it matters, I don't think 16-bit programs run on x64 Windows. Also, some software which controls hardware (i.e. rmclock, i8kfangui) will not run despite being x64 compatible because the driver isn't signed. depending on the program you will jump through hoops to get it to work properly (rmclock is an easy fix since, i8kfangui isn't)

 

[Scali]

If it matters, I don't think 16-bit programs run on x64 Windows

That is correct (with the exception of using something like DOSBOX or VirtualPC to run a 16/32-bit OS from within the x64 OS).

 

[Voo]

Also, some software which controls hardware (i.e. rmclock, i8kfangui) will not run despite being x64 compatible because the driver isn't signed. depending on the program you will jump through hoops to get it to work properly (rmclock is an easy fix since, i8kfangui isn't)

No experience with that software, but if it's just the unsigned driver, why not just use the testsigning mode and sign the drivers yourself?

@Scali: Actually only the top end servers had real PAE support, so even with a server OS you didn't necessarily get lots of RAM - which on the server side was obviously just done to get people to pay more for the more expensive versions..

 

[Scali]

@Scali: Actually only the top end servers had real PAE support, so even with a server OS you didn't necessarily get lots of RAM - which on the server side was obviously just done to get people to pay more for the more expensive versions..

Here you go:
http://www.microsoft.com/whdc/system/platform/server/pae/paedrv.mspx

 

[Seero]

I have heard that 64 bit architecture does not outperform 32 bit because 32-bit applications do not take advantage of the oversized processors since they run under a backward compatibility mode. To take advantage of the 64-bit the old 32-bit apps should be rewritten or at least recompiled.

In other words, buying a 64-bit laptop, configured with Win 7-64, is just a waste of money if I don't buy 64-bit apps. Is that true?

Think of CPU as a bus with 32 seats, and the OS is the seat plan, also 32 seats. It doesn't make since in the case above to use 64 seats plan as the bus can only handle 32 seats(people) each pass, requires 2 passes for 64 seats which doubles the travel time. Yet, if the bus has 64 seats, it also doesn't make sense to use 32 seat plan as half of the seats are completely unused.

Unless you are still using pentimum or older CPU, it is 64 bit. There is no reason why not to upgrade to 64 bit OS. 32 bit apps runs as fast as in 32 bit OS on 64bit OS. 32 bit apps have a soft memory cap of 2 gb under 32 bit OS, hard cap at 3gb. On 64 bit OS, 32 bit can use up to 4gb. 32 bit OS can't support more than 4gb physical memory usage, OoM errors starts to pop left and right when the total memory usage gets close to 4gb even with a large pagefile. Under 64 bit OS, depending on which version, support 8-128gb memory usage.

It will be stupid to use 128bit OS now as CPU isn't there yet, but eventually, it will become the smart choice.

 

[rudder]

64-bit is faster, but apps have to be recompiled to take advantage of 64-bit mode, which supplies extra registers to use.

Which is happening slowly (i.e. photoshop cs4 and cs5 64 bit versions). Might as well go 64 bit now... you may not gain much now, but you are not losing anything. 64bit OS costs the same... and all cpu's are 64bit capable.

 

[M1A]

Shouldn't this be in the OS forum as its not CPU or Overclocking? Well maybe if you were talking 64bit processors....

 

[Markfw]

Shouldn't this be in the OS forum as its not CPU or Overclocking? Well maybe if you were talking 64bit processors....

Well, you have a point, except I think the question is global, as in "are 64 bit processors faster", and to answer that, you have to involve software.

I don't like being nitpicky....

 

[Cogman]

There are SOME areas where a 64bit application will be able to outperform its 32bit counterpart, but those are few and far between. The extra addressable memory without a speed hit is the biggest reason to go 64 bit.

 

[ModestGamer]

There are SOME areas where a 64bit application will be able to outperform its 32bit counterpart, but those are few and far between. The extra addressable memory without a speed hit is the biggest reason to go 64 bit.

the next leap in CPU technology will not be integrated GPU style cores. It will be in integrated ram becuase buss speeds are choking the cpu's. thats why cache sizes keep going on.

 

[Cogman]

the next leap in CPU technology will not be integrated GPU style cores. It will be in integrated ram becuase buss speeds are choking the cpu's. thats why cache sizes keep going on.

Bus speeds really aren't hurting modern CPUs. Don't believe me? look at any review that tests the difference between higher clocked ram vs lower clocked ram. The difference in just about every program is near 0. Synthetic tests are usually the only place that really sees a difference between slow and fast ram.

That isn't to say a faster memory accesses wouldn't be nice, just that they aren't a huge issue for most applications (Though, faster memory would probably introduce bigger performance increases than the switch from 32->64 bit).

That being said, the GPU has more of a memory requirements than the CPU does (Loading textures, vertices, ect), so a fastest memory WOULD give a noticeable speed increase to the GPU.

I personally think that we will see a large increase of optical interconnects (rendering bus speed concerns pretty silly. Latency still exist but that is what cache smooths out.)

Who knows though, maybe one day a tech like ZRAM, PRAM, or MRAM will take off, causing our on die cache to jump from 10MB to 128MB+. I don't, however, for see a company putting DRAM on a CPU. Latency and bus speeds aren't the biggest concerns when dealing with DRAM. DRAM itself is pretty slow. (Hence the reason DDR->DDR3 try to avoid this by trying to access several DRAM sections at once)

 

[Scotteq]

Yes, that is it. Whatever it is called, it was an unexpected and painful wall of bricks to stumble to on "simple" port of "simple" application.

Correct - Handles in Win 64 have 32 significant bits. Can't truncate to 16 bits without... well... F*cking Them Up Beyond All Recognition. D:

and yah - That's a deep technical term: FUBAR

 

[lillyfrey]

I have been using a 64-bit for about two weeks now and I don't see a difference ... then again, I'm not doing anything serious on it either. Maybe if I was a big gamer/video editor I would notice a difference.

 

[Scotteq]

I have been using a 64-bit for about two weeks now and I don't see a difference ... then again, I'm not doing anything serious on it either. Maybe if I was a big gamer/video editor I would notice a difference.

In the case of Windows - Win 64 comes with a complete set of 32 bit libraries so your (32 bit windows) apps can be run transparently to the app. Out of necessity, there is a little jiggery pokery on the back end: For example, dlls which have to directly share 64 bit resources use a custom calling sequence instead of the native x86. Windows then plays traffic cop with these custom calls.

http://msdn.microsoft.com/en-us/library/aa384274(v=VS.85).aspx


But anyways - Since your apps are running in 32 bit mode, against 32 bit libraries, there is no real performance difference.

 

[Schmide]

Correct - Handles in Win 64 have 32 significant bits. Can't truncate to 16 bits without... well... F*cking Them Up Beyond All Recognition. D:

and yah - That's a deep technical term: FUBAR

Handles in win32 have 32bits as well, why would you be truncating them to 16bits anyways?

BTW in 64bit windows they have 32bits as well, if you do cast/extend them to a quadword the upper 32bits can be ignored.