LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware still rocks! -just a cheer for Slackware - and one question :) (https://www.linuxquestions.org/questions/slackware-14/slackware-still-rocks-just-a-cheer-for-slackware-and-one-question-4175469216/)

273 07-12-2013 07:19 PM

Quote:

Originally Posted by jtsn (Post 4989354)
The part that takes most advantage of being 64 bit is the kernel, install it and you are already 90 % there. Userland applications are not a big deal yet (!), most 64 bit PCs in the world run a 64 bit OS kernel with 32 bit applications, which is currently the sensible thing to do.

Citation needed?

jtsn 07-12-2013 07:37 PM

Quote:

Originally Posted by 273 (Post 4989359)
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.

Gerard Lally 07-12-2013 07:52 PM

Quote:

Originally Posted by jtsn (Post 4989298)
If you don't want a multilib system, you can drop a 64 bit kernel into /boot, install the 64 bit modules and boot your 32 bit userland without additional efforts or changes to the system ...

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.

Richard Cranium 07-12-2013 07:56 PM

Quote:

Originally Posted by jtsn (Post 4989363)
[...] but that is not how the software industry works.

Depends on the portion of the industry.

NoStressHQ 07-12-2013 08:44 PM

Quote:

Originally Posted by 273 (Post 4989351)
There's a thread on this forum that suggests that 64 bit floating point is slower than 32 bit...
Aside from that -- [...]

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.

jtsn 07-13-2013 03:48 AM

Quote:

Originally Posted by gezley (Post 4989368)
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?

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).

273 07-13-2013 05:40 AM

Quote:

Originally Posted by jtsn (Post 4989363)
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.

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.
Quote:

Originally Posted by NoStressHQ (Post 4989388)
Do you have a link to that ? That sounds very strange to me.

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/

jtsn 07-13-2013 02:14 PM

Quote:

Originally Posted by 273 (Post 4989560)
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.

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.

273 07-13-2013 02:24 PM

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.

Gerard Lally 07-13-2013 03:25 PM

Quote:

Originally Posted by jtsn (Post 4989507)
You put them into /lib/modules as if they were 32 bit modules.

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.)

ntubski 07-13-2013 04:27 PM

Quote:

Originally Posted by 273
There's a thread on this forum that suggests that 64 bit floating point is slower than 32 bit...
...
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/

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.

273 07-13-2013 04:29 PM

Quote:

Originally Posted by ntubski (Post 4989805)
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.

jtsn 07-13-2013 04:41 PM

Quote:

Originally Posted by gezley (Post 4989783)
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.)

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.

jtsn 07-13-2013 04:57 PM

Quote:

Originally Posted by 273 (Post 4989765)
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.

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.

Quote:

If you don't have more than 4GB of memory then you don't "need" a 64 bit kernel
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.

Gerard Lally 07-13-2013 05:09 PM

Quote:

Originally Posted by jtsn (Post 4989811)
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.

Very interesting. Thank you.


All times are GMT -5. The time now is 05:37 AM.