Citation needed?

Just one example: http://store.steampowered.com/hwsurvey/

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.

OK I know how to compile a kernel and install modules on a 64-bit system, and then drop the 64-bit kernel into /boot on a 32-bit system, but how would I install the 64-bit modules on the 32-bit system? I'm curious; I've never heard of this being done.

Depends on the portion of the industry.

Do you have a link to that ? That sounds very strange to me. Although I shouldn't speak without having profiled myself, I did a lot of FPU programming for 20years, x86 (87) FPUs works in 64bits internally, and if we used 32 floating points, it's just for a question of memory space an bandwidth. So it might be a bandwith problem but shouldn't be a processing problem... What might be slower is maybe (I guess, as I said I just answer "on the fly"), the convertion from 64bit to 32bit when we are in 64bit mode, as it might expect a path to 64bit stored FP, and reducing to 32 bits FP as most programs use could have some penalty.

Anyway, if you have more info on this, I'd be curious to know why this behavior would come from.

Thanks !

Cheers

Garry.

You put them into /lib/modules as if they were 32 bit modules. If you plan to use the stock slackware64 kernel, you just replace the stock i486 kernel with it (it's not needed anyway). You can keep the default i686-smp kernel in parallel, because it loads its modules from a path like /lib/modules/3.2.29-smp (in 14.0).

That neither says that the kernel is the part that mainly takes advantage of 64 bit hardware nor that most applications run on 64 bit hardware are 32 bit and it specifically does not say that running 32 bit applications on a 64 bit kernel is sensible. If you want to talk about Windows and third-party applications that's fine but I don't see the relevance to a Linux forum nor is it talking about what is sensible or possible. For the record the only 32 bit application I am running since Google Earth went 64 bit is a second Life viewer and that's only because my current OS has some dependency issues -- otherwise I'd be entirely 64 bit.
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.
It sounds very strange to me also, if you can explain it another way I'd feel a little reassured:
http://www.linuxquestions.org/questi...ux-4175464890/

This is not Wikipedia.

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.

Do you overwrite existing modules which have the same name? (I'm not able to test at the moment because the PSU has blown in my main machine.)

The program in that thread is using integers, not floating point. The same speed advantage can be obtained when compiling a 64bit executable by changing unsigned long to uint32_t.

Aha, thanks for that. Looks like I should have read the code more closely (I think somebody mentioned floating point so I took it to be that). Mea culpa.

On Slackware 14.0 you uninstall

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.

1 members found this post helpful.

I'm just showing people an option they have, if they are not ready to go full 64 bit. By just booting an 64 bit kernel, they immediately gain advantages without sacrificing RAM and disk space or having to reinstall. Also without having to maintain of a multilib system. There is a reason, why Slackware64 is not a OOtB multilib system, but pure 64 bit.

And that is plain wrong on Linux. You "need" a 64 bit kernel once you go over 1 GB (896 MB exactly), this is where slow ZONE_HIGHMEM comes into play. If you can live with the performance penalty of it, then you can go up 64 GB on 32 Bit.

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.

Very interesting. Thank you.