10

This is a very basic doubt that I have. I am not an IT or CS guy so please try to explain in simple language. Now why I am asking that question is that because we can run 32 bit apps in 64 & 32 bit OS's. AFAIK the data types for 64 bit take double amount of memory than 32 bit apps. Also 64 bit apps can only run on 64 bit OS's. Then why take the trouble of building 64 bit applications? Perhaps thats why Firefox is available only in 32 bit??? Sorry if this question is not on par with the standards of SO, but I just cant control stop thinking about the same. Thank You.

UPDATE: Somehow there seems to be a confusion. I did not mean to question why we need a 64 bit architecture machine. I know that 32 bit machines can only use 4GB RAM & 64 bit machines have much higher limit. I was questioning why we need to build 64 bit Applications!

Cool_Coder
  • 4,888
  • 16
  • 57
  • 99
  • Ever tried to allocate 150GiB of ram in a 32bit process? – PlasmaHH Apr 11 '13 at 12:28
  • 4
    64-bit applications can access more memory. This important for some applications, not so much for others. – john Apr 11 '13 at 12:28
  • @PlasmaHH what is GiB? is it related to giga bytes (GB)? – Cool_Coder Apr 11 '13 at 12:34
  • 3
    @Cool_Coder it probably is "Gigantomatic Bytes" – TheBlastOne Apr 11 '13 at 12:35
  • Note that on 32-bit Windows, 32-bit applications have only a 2 GB virtual address space (you can [increase it up to 3 GB](http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx)), the rest is reserved for the OS. If you run a 32-bit application on a 64-bit Windows, it gets the full 4 GB virtual address space, as the OS can make use of the higher 64-bit addresses. With [AWE](http://msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx), you can make use of more than 4 GB RAM (!) in your 32-bit application, but 64-bit native is less effort. – dyp Apr 11 '13 at 12:50
  • 1
    @Cool_Coder: http://en.wikipedia.org/wiki/GiB – PlasmaHH Apr 11 '13 at 12:52

4 Answers4

11

Aside from the OBVIOUS reasons given above (mainly "using more than 2-3GB of memory"), the reason to compile for 64-bit is that x86-64 has 16 registers, where x86-32 has 8. Since one of those registers is the stackpointer and often rBP is reserved for "framepointer", the actual useful number of registers is 6 and 14 respectively. The additional registers allow, for example, larger number of parameters being passed in registers, and larger number of temporary variables being held in registers within a function. This has a positive effect on the actual execution speed of the code, as every time memory is used instead of a register, AT LEAST it leads to a more complex instruction, and often to an additional instruction having to be used. This in turn makes the code larger when there isn't enough registers.

Generally, 64-bit x86 code runs some 5-15% faster with no modification to the actual algorithms, and typically has . Sometimes algorithms can be changed to gain much more [because for example you can have an array that is indexed by "telephone number", instead of hashing the phone number and then indexing on the hash, or making use of 64-bit integer values instead of 32-bit ones, meaning a speedup of 2x for "half as many operations"].

If it's performance you need from the application, you will have to benchmark (on multiple platforms). There are situations where, for example, larger pointers, mean that cache gets full more quickly and the code ends up running slower because "only half as many linked list entries fit in the cache".

In short: In most cases, 64-bit apps are faster than 32-bit apps doing the same thing.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • 32-bit apps can access 4GB on 64 bit windows with \LARGEADDRESSAWARE switch: http://support.microsoft.com/default.aspx?scid=889654 – EdChum Apr 11 '13 at 12:52
  • 1
    And they can access more than 4 GB with [AWE](http://msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx) – dyp Apr 11 '13 at 12:53
  • 1
    Yes, both of those are true (well, it's "Just under 4GB", but for all intents and purposes it's 4GB). AWE doesn't give you one large lump of memory, but the code has to jump through hoops to use the memory, which is not a good solution. – Mats Petersson Apr 11 '13 at 12:58
  • @MatsPetersson thanks for that highly technical answer which I am unable to most of it. But what I understood is that 64 bit apps are faster than 32 bit apps under some conditions. – Cool_Coder Apr 11 '13 at 13:18
  • Yes, in short, 64-bit is faster than 32-bit most of the time. – Mats Petersson Apr 11 '13 at 13:24
6

The most important usecase is when you really want to consume more than 2 gigabytes memory for your process.

The next thing is 32-bit support will slowly decline just like you won't see many 16-bit apps now. This is a slow process though. Currently there's one version of Windows Server 2008 that doesn't have 32-bit support by default.

And finally sometimes you just have to be 64-bit - that's when you build an extension of any kind that is loaded into a 64-bit consumer process. Since 64-bit processes can't load 32-bit code you have to supply a 64-bit extension for them or craft an interop solution to have your code in a separate process - the latter is not always possible and is sometimes very inefficient.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • Thank You for your simple answer as I had asked. However I could not understand the 3rd paragraph. – Cool_Coder Apr 11 '13 at 12:48
  • @Cool_Coder: Which thing exactly do you not understand? – sharptooth Apr 11 '13 at 12:49
  • 32-bit apps can access 4GB on 64 bit windows with \LARGEADDRESSAWARE switch: http://support.microsoft.com/default.aspx?scid=889654 – EdChum Apr 11 '13 at 12:51
  • @EdChum: This requires lots of jumps through hoops and you still can't use all of 4 GB. – sharptooth Apr 11 '13 at 12:57
  • What I understood was that suppose there is a 64 bit .exe. Then if it needs a .dll then I have to build the dll in 64 bit & 32 bit wont work for 64 bit exe, right? But what did you mean by "or craft an interop solution to have your code in a separate process - the latter is not always possible and is sometimes very inefficient." – Cool_Coder Apr 11 '13 at 13:01
  • @Cool_Coder: For example, you can do the following: put all your code into a 32-bit .exe and then craft a dumb wrapper 64-bit .dll that will just run that .exe and get results from it. This way you don't need all your code to be 64-bit and your code can be used from 64-bit program. That's just the dumbest interop example to show you the idea. – sharptooth Apr 11 '13 at 13:05
  • ok I got the idea, thanks – Cool_Coder Apr 11 '13 at 13:16
5
  • Physical memory

A 32-bit system architecture can directly address only a 4-GB address space. A 64-bit system architecture that is running a 64-bit edition of Windows Server can support up to 1,024 GB of both physical and addressable memory.

  • Better parallel processing

A server that is using 32-bit architecture is limited (Windows OS) to 32 CPUs. Improvements in parallel processing and bus architectures enable 64-bit environments to support as many as 64 processors and provide almost linear scalability with each additional processor.

  • Faster bus architecture

A 64-bit architecture provides more and wider general-purpose registers, which contribute to greater overall application speed. When there are more registers, there is less need to write persistent data to memory and then have to read it back just a few instructions later. Function calls are also faster in a 64-bit environment because as many as four arguments at a time can be passed in registers to a function.

Leo Chapiro
  • 13,678
  • 8
  • 61
  • 92
1

The size of data types does not automatically double with x64, but the size of the processors registers, just as the pointer size does. With 32 bits you are able to address 4294967295 bytes of memory (~ 4 Gb), which is not enought for some applications (like database management systems, ...).

Firefox is only available in 32-bit, because of compatibility issues. You cannot write libraries for x86 (32 bit) architectures and call them from x64 processors, because their pointers are incompatible (as described above). Creating both: x64 and x86 versions increases test-expense. If your application rarely uses more than 3.5 Gb memory, then it doesn't actually profit from x64 architectures.

Also 32 bit programms cannot simply run on x64 architectures. On Windows there is a layer for this, called Windows on Windows (WoW), or WoW64 for x64/x86 interfaces. Through various caching cases it may also be that an x86 application runs actually faster on WoW, than an native x64 application, doing the same.

Carsten
  • 11,287
  • 7
  • 39
  • 62
  • Hey @Aschratt thanks for that info, I didnt know that. So Windows has this speciality only of running 32 bit apps on 64 bit OS? Doesnt 64 bit Ubuntu run 32 bit apps by default. I am asking because I dont know. – Cool_Coder Apr 11 '13 at 13:06
  • I don't know if Linux (or Ubuntu) has such a abstraction layer. Basicly WoW64 "simulates" an x86 processor to the x86 process. This is not very hard, because most opcodes are the same, all it needs to do is fix the pointers. I think there's something similar for Ubuntu, but I really don't know. – Carsten Apr 11 '13 at 13:08