Hi

Im setting up some servers and those servers are running a 64-bit version of a linux distribution. Im for example going to run the application server "resin" and the program jmagic. The servers will probably receive very many queries from clients, so this wont be a light traffic server.

What im wondering is how much difference it will make to install a 32-bit version of "resin" instead of a 64-bit and the same question goes about jmagic.

Thanks for all help, its appericiated.

32-bit vs 64-bit has really nothing to do with performance. Sure, its possible the 64-bit might be faster, but only in a few special cases. You should not expect to see that much of a performance difference (unless those programs happen to do a lot of special math).

Usually, the 32-bit version is slightly faster than the 64-bit, but there are also cases of the opposite. One reason to use 64-bit might be that you have more than 4 GB RAM, even tho there are ways around this as well.

While there is little if any discernible difference in the apparent quickness of 64 and 32 bit systems, that will soon change. Already, in Debian at least, 64-bit development is beginning to run ahead of 32-bit since most of the developers are using 64-bit systems. Within a year or two 32-bit applications will begin to fall by the wayside as the move to 64-bit gains critical mass.

I don't intend to do any more "from scratch" installations during that time unless it's on a new machine. Every installation I do now is 64-bit because it's the OS of the near future, and I lose nothing by going there now.

Databases are one type of application that tends to run faster on a 64 bit system as are multimedia processing applications and other highly CPU intensive ones. For the rest, it doesn't really make any difference at this time. But as suggested above, if you have or are going to have more than 3GB of RAM (not 4) , getting it to work with a 32 bit OS takes extra effort so you may as well choose 64 bit.

Thanks for replying.

Could you please explain why the developers have choosen to move over to 64-bit systems if there isnt any notable advantages of doing so? And, it seems like pretty much everyone wants to run 64-bit software these days which confuses me a little since i dont see any more advantages with using 64-bit instead of 32-bit (I thought there was a performance loss when using 32-bit applications on a 64-bit system, but i was wrong here?)

Some of the servers have 2GB of RAM and some other servers have as much as 16GB. When you say that there will be problems when using a 32-bit version of the OS when having more than 4GB of RAM installed, do you then mean that 32-bit versions of the OS doesnt support larger memory support than 4GB?

Also, if you install a 32-bit version of a linux distribution and the server has over 4GB of memory, what kind of problems can this cause?

I think you might be wrong here. 32-bit vs. 64-bit does have to do with performace, but not only with performance. I have talked to some of the unix staff and they say that as long as the applications has been written to take advantage of 64-bit, then it can and will be an increase in performance.

If you install a compiled 32 bit binary, it may have been compiled for the 386 architecture.

A 64 bit application will also be able to use >2 GB of ram. for some applications this may make a difference. I imagine that a version written for a 64 bit processor may be more likely written to take advantage of other things like multithreading on multi-core processors.

Unless a program uses plugins that don't have 64 bit versions, I don't see any reason to install a 32 bit program on a 64 bit machine.

The PAE feature of the CPU is needed to use more than 4Gb of physical address space with a 32 bit kernel. A full 4Gb of RAM requires more than 4Gb of physical address space because the BIOS and/or chipset map other things into the first 4Gb of physical address space. Some systems fit as little as three and an eighth Gb of RAM in the first 4Gb physical.

I have read vague posts about some things not working with PAE. Certainly it presents an extra layer of complication on the boundary between the kernel and any DMA device driver. I don't know if PAE is really incompatible with anything or really reduces any performance. The posts I've seen have little if any detail. The Linux servers used by my employer include 32 bit PAE kernels with up to 8Gb of ram. No one there has mentioned any PAE specific problem.

There are a bunch of reasons why a 64 bit application should be faster than 32 bit and a bunch of reasons why a 64 bit application should be slower than 32 bit. But I haven't seen any benchmarks fairly comparing them. There just seems to be anecdotal evidence saying performance is pretty much the same.

The 32 bit PAE kernel should be a little slower than the 32 bit non PAE kernel, but not by enough to be worth using non PAE 32 bit if that costs some of your total ram. Again, I haven't seen any measurements of the difference.

Running 32 bit applications on a 64 bit kernel gives you a little more virtual memory than the same applications on a 32 bit kernel. At work, I use programs where that makes a significant difference. Most Linux users don't ever use such applications. Assuming you don't need that extra virtual memory, the difference between a 32 and 64 bit kernel when running a 32 bit application should be pretty subtle. Again, I haven't heard of anyone measuring it.

I'd like to see some benchmarks, I'll look around for some, but if anyone already has found some good ones, please post a link.

Back in the day when Computer Shopper in the UK had a dedicated Linux column they did do some benchmarking when AMD first had its 64 bit arch available.

From what I remember, in none of the combinations that they tested was there a dramatic difference one way or the other, and some of the combinations were out and out puzzling. However, what you can say is:

i) It depends

ii) If you need the extra memory space, then you probably have no choice

iii) If you are going to run proprietary apps which are not available in 64 bit form, there is a case for not bothering with 64 bit, except if ii) above applies

iv) If you were just changing to 64 bit and didn't need the extra addressing range, a legitimate expectation would be that this would slow down applications slightly

v) iv) above doesn't really apply... At least with the AMD implementation, at the same time as extending the instruction set to 64 bits they also did some minor clean up of the instruction set, which did result in some minor speed-ups (and then there are the streaming/multi-media extensions...in general 32 bit programs will be compiled for a lowest common denominator 32 bit CPU (so, with a relatively low numbered version of streaming extension) and the 64 bit code will be compiled for a low level of streaming extension for a 64 bit processor which will be a lot more competent
(although the streaming stuff doesn't have much impact on general purpose code but in the special cases in which they are significant, they are very significant)

vi) and then the Intel implementations probably have some differences to the AMD ones which may or may not be significant. Certainly, historically, the Intel compiler has been better at shoving out code specifically optimised for the requirements/preferences of its newer CPUs than gcc has. (Although, usually, as most stuff is optimised for the 'lowest common denominator' processor, this may well be of zero significance. Or not.)

Did I say it depends?