Quote:
|
Quote:
Most used OS version: Windows 7 64 Bit (53 %) Almost anything in the Steam Store: 32 Bit applications (because having one binary for both 32 and 64 bit platforms reduces maintenance burden a lot) I know that on Linux we compile everything for 64 Bit, but that is not how the software industry works. |
Quote:
|
Quote:
|
Quote:
Anyway, if you have more info on this, I'd be curious to know why this behavior would come from. Thanks ! :) Cheers Garry. |
Quote:
|
Quote:
For an illustrative anecdotal example a friend recently moved from 32 bit to 64 bit Ubuntu and cursed me for not persuading him to sooner such was the improvement in usage of 64 bit Ardour on a 64 bit kernel. I am guessing due to it actually using the denormal handling of the SSE instructions rather than it being 64 bit -- which is one of the things I was talking about in my original post about applications compiled for 64 bit taking advantage of more modern features also. The kernel does not use any floating-point instructions and specifically does not use SSE so this kind of thing cannot be anything to do with the kernel. Quote:
http://www.linuxquestions.org/questi...ux-4175464890/ |
Quote:
Running a 64 bit kernel removes the address space constraints from the kernel (which is worth a lot) and allows 32 bit user space processes to make use of full 4 GiB (which is enough for most applications). There is no further advantage in having a 64 bit /sbin/init oder a 64 bit /sbin/sh. You just get additional overhead, cache pollution and memory usage. There is an ABI specification for Linux in development, which specifically allows the creation of 32 bit applications without sacrificing the advantages of modern 64 bit CPUs: http://www.linuxplumbersconf.org/2011/ocw/sessions/531 These applications don't run on real 32 bit systems and require a 64 bit kernel. Such developments wouldn't exist, if everything is just fine with pure 64 bit. |
You have still not given any source to support your opinion that running 32 bit applications on a 64 bit OS is the sensible approach or what most people are doing.
If you don't have more than 4GB of memory then you don't "need" a 64 bit kernel and if you do then the fact that 64 bit applications may use more memory becomes less relevant with <4GB to play with. The strange result I mentioned earlier for floating point aside I would deduce that it is only in special cases that you would specifically want to run 32 bit applications on a 64 bit kernel as a preference. Apologies for going on about this but I find broad generalisations without evidence to be harmful when trying to understand a subject. |
Quote:
|
Quote:
|
Quote:
|
Quote:
kernel-generic-3.2.29-i486-1 kernel-huge-3.2.29-i486-1 kernel-modules-3.2.29-i486-1 first, then nothing will be overwritten. The default 32 bit kernel/modules packages for modern SMP machine are named differently: kernel-huge-smp-3.2.29_smp-i686-1 kernel-generic-smp-3.2.29_smp-i686-1 kernel-modules-smp-3.2.29_smp-i686-1 The modules of the latter don't conflict with the 64 bit packages: kernel-huge-3.2.29-x86_64-1 kernel-generic-3.2.29-x86_64-1 kernel-modules-3.2.29-x86_64-1. So if you do it right, you have the 64 bit modules sitting in /lib/modules/3.2.29 (and not the i486 cruft) and the 32 bit modules in /lib/modules/3.2.29-smp. The kernels are /boot/vmlinuz-huge-3.2.29 (64 bit) and /boot/vmlinuz-huge-smp-3.2.29-smp (32 bit) respectively. You could also grab the kernel packages from -current, if the kernel version differs (like 3.9), there is not even the chance of conflicts. If you configure LILO correctly, you should be able to choose the kernel flavor on every boot. And go back to pure 32 bit, if issues arise. |
Quote:
Quote:
Above 4 GB RAM there is exactly not a single reason for switching to 64 bit, that doesn't apply to 1 GB or 2 GB systems also. |
Quote:
|
All times are GMT -5. The time now is 05:37 AM. |