LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-12-2013, 07:19 PM   #16
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,411

Rep: Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794

Quote:
Originally Posted by jtsn View Post
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?
 
Old 07-12-2013, 07:37 PM   #17
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by 273 View Post
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.

Last edited by jtsn; 07-12-2013 at 07:38 PM.
 
Old 07-12-2013, 07:52 PM   #18
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware64, NetBSD
Posts: 504

Rep: Reputation: 209Reputation: 209Reputation: 209
Quote:
Originally Posted by jtsn View Post
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.
 
Old 07-12-2013, 07:56 PM   #19
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.1
Posts: 1,516

Rep: Reputation: 444Reputation: 444Reputation: 444Reputation: 444Reputation: 444
Quote:
Originally Posted by jtsn View Post
[...] but that is not how the software industry works.
Depends on the portion of the industry.
 
Old 07-12-2013, 08:44 PM   #20
NoStressHQ
Member
 
Registered: Apr 2010
Location: Lausanne - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware Leet - 32/64bit
Posts: 283

Rep: Reputation: 94
Quote:
Originally Posted by 273 View Post
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.
 
Old 07-13-2013, 03:48 AM   #21
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by gezley View Post
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).
 
Old 07-13-2013, 05:40 AM   #22
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,411

Rep: Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794
Quote:
Originally Posted by jtsn View Post
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 View Post
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/
 
Old 07-13-2013, 02:14 PM   #23
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by 273 View Post
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.
 
Old 07-13-2013, 02:24 PM   #24
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,411

Rep: Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794
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.
 
Old 07-13-2013, 03:25 PM   #25
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware64, NetBSD
Posts: 504

Rep: Reputation: 209Reputation: 209Reputation: 209
Quote:
Originally Posted by jtsn View Post
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.)
 
Old 07-13-2013, 04:27 PM   #26
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian
Posts: 2,492

Rep: Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850Reputation: 850
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.
 
Old 07-13-2013, 04:29 PM   #27
273
Senior Member
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 3,411

Rep: Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794
Quote:
Originally Posted by ntubski View Post
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.
 
Old 07-13-2013, 04:41 PM   #28
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by gezley View Post
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.

Last edited by jtsn; 07-16-2013 at 07:18 AM.
 
1 members found this post helpful.
Old 07-13-2013, 04:57 PM   #29
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by 273 View Post
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.

Last edited by jtsn; 07-13-2013 at 05:25 PM.
 
Old 07-13-2013, 05:09 PM   #30
gezley
Member
 
Registered: Sep 2009
Location: Ireland
Distribution: Slackware64, NetBSD
Posts: 504

Rep: Reputation: 209Reputation: 209Reputation: 209
Quote:
Originally Posted by jtsn View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Trying not to sound too much like a teenager, but Slackware Rocks! Newt_Othis LinuxQuestions.org Member Intro 0 08-22-2011 10:42 AM
a non-slackware question that can (probably) be solved by slackware nass Slackware 6 03-02-2011 03:50 PM
slackware current rocks! denning Slackware 17 02-07-2005 01:56 PM
Slackware Live CD rocks! Must have! Whitehat General 7 08-28-2003 09:48 AM


All times are GMT -5. The time now is 01:38 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration