LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
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 09-27-2015, 10:31 AM   #16
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231

Quote:
Originally Posted by Richard Cranium View Post
I agree that any task which requires a 32 bit library to run is a trivial one.
Of course, with a bit of LOL!

Sorry, but honestly I consider LOL as an insult to KISS and Slackware principles. Sorry, Eric, but is not a personal attack!

Anyway, those who have balls to go x64, should go x64, not to come there claiming that "they run x64" while almost entire operating system is duplicated with x86 thingies.

Last edited by Darth Vader; 09-27-2015 at 10:32 AM.
 
Old 09-27-2015, 10:32 AM   #17
enine
Senior Member
 
Registered: Nov 2003
Distribution: Slackware 14.2, SlackwareArm-current
Posts: 1,215
Blog Entries: 4

Rep: Reputation: 183Reputation: 183
I tried x64 on a 2G machine and just simple web browsing it would hit swap often.
Now on my 4G laptop x64 works well.
 
Old 09-27-2015, 10:37 AM   #18
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231
Quote:
Originally Posted by enine View Post
I tried x64 on a 2G machine and just simple web browsing it would hit swap often.
Now on my 4G laptop x64 works well.
QED. In other hand, your 4GB laptop, running x64 behave like one with 2GB running x86. I wonder, again, why you waste your system resources...
 
Old 09-27-2015, 11:21 AM   #19
WiseDraco
Member
 
Registered: Nov 2006
Location: Europe,Latvia,Riga
Distribution: slackware,slax, OS X, exMandriva
Posts: 591

Original Poster
Rep: Reputation: 72
Question

Quote:
Originally Posted by Darth Vader View Post
QED. In other hand, your 4GB laptop, running x64 behave like one with 2GB running x86. I wonder, again, why you waste your system resources...
absolutely cannot understand, about what you talking.
4 Gb is 4 Gb, not important, under a x86 or under x64 OS - it is the same 4 Gb.
from where you get idea, that a using x64 OS cut off half of CPU, FPU, RAM, HDD size, and half an user? :-O
 
Old 09-27-2015, 12:05 PM   #20
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231Reputation: 1231
Quote:
Originally Posted by WiseDraco View Post
absolutely cannot understand, about what you talking.
4 Gb is 4 Gb, not important, under a x86 or under x64 OS - it is the same 4 Gb.
from where you get idea, that a using x64 OS cut off half of CPU, FPU, RAM, HDD size, and half an user? :-O
It's something like every program consume a double amount of memory, in x64 environment, compared with a x86 (i586) one. In other hand, the both environment behave equal, until you have more than 4GB RAM, where you hit the PAE program limitation (max 4GB memory per program). A very wise decision, second me, because I believe that any respectable program should not hit that barrier ever and if it hit that barrier, it should be respectfully nuked from orbit. The next x86 barrier is hit on 64GB memory, max possible to be used under a x86 environment.

In few words, I believe that, until you system have more than 64GB memory, using x64 is just a perfect method to look cool and to seriously waste you system resources.

Last edited by Darth Vader; 09-27-2015 at 12:06 PM.
 
Old 09-27-2015, 12:11 PM   #21
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 890

Rep: Reputation: 419Reputation: 419Reputation: 419Reputation: 419Reputation: 419
you've made your point Darth, take a rest :P
 
Old 09-27-2015, 12:15 PM   #22
hitest
Guru
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 5,586

Rep: Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634Reputation: 1634
I would go with 32 bit slackware-current on the netbook.
 
Old 09-27-2015, 12:56 PM   #23
WiseDraco
Member
 
Registered: Nov 2006
Location: Europe,Latvia,Riga
Distribution: slackware,slax, OS X, exMandriva
Posts: 591

Original Poster
Rep: Reputation: 72
Quote:
Originally Posted by Darth Vader View Post
It's something like every program consume a double amount of memory, in x64 environment, compared with a x86 (i586) one.
on my experience, x64 not consume double as x86. it is a bit more, but no double.
on a systems with 4 and more Gb RAM there is no question about usage of x64 for me .
memory limit for x86 processe, FYI, is not 4 Gb, but about 3.4Gb.

anyway, thanks all for your advices, i decide try a x86 version of slack current on brothers netbook.
BTW, about XFCE in current ( 4.12) - that also need to be add keyboard layout switcher to can use different keyboard layouts?
in 14.0 and 14.1 it is a bit surprisingly for me - KDE nor Hnome not require additional modules for can use different keyboard layouts...
 
Old 09-27-2015, 01:00 PM   #24
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860
Quote:
Originally Posted by Darth Vader View Post
I for one, I need my computers to work at full power...
And you achieve that with not using the extended capabilities (like larger registers, more registers) of your CPU and having more overhead in the virtual memory manager?
That sounds weird.

Anyways, just for fun I went ahead and made a test: I installed Slackware and Slackware 64 each into their own VM (2 CPUs, 2GB RAM, 2GB swap, 10 GB ext4 /-partition, 64MB RAM for the virtual video adapter, XFCE desktop started from runlevel 3 with startx, huge kernel) and looked at the numbers.
Host hardware: AMD Phenom II X6 1055T CPU (6 cores, 2.8GHz) with 16GB DDR3-1333 RAM, tests done on a mechanical RAID 1 array formatted with BTRFS (with chattr -C for the directory that contains the disk images to prevent performance problems).

Running Firefox displaying the LQ startpage and xfce4-terminal:
Slackware 32 bit: 294MB of memory used, 0 MB of swap, htop jumps between 2% and 6% CPU usage on both cores, mostly around 4%
Slackware 64 bit: 374MB of memory used, 0 MB of swap, htop jumps between 1% and 4% CPU usage on both cores, mostly around 3%

Running Firefox playing a 360p video on Youtube and xfce4-terminal
Slackware 32 bit: 330MB of memory used, 0MB of swap, htop reports around 30% CPU usage on both cores
Slackware 64 bit: 440MB of memory used, 0MB of swap, htop reports around 28% CPU usage on both cores

Then let's get to something trivial and run a simple command:
Code:
tar -czf linux.tgz /usr/src/linux-3.10.17
Slackware 32 bit: 65 seconds
Slackware 64 bit: 65 seconds

So, so far 64 bit has a small advantage in CPU usage, but higher RAM consumption, but still with plenty of headroom.

Let's get to a more heavy task: I installed ffmpeg (the restricted version) from AlienBob's repository in both VMs and used it to extract the audio part of the 480p MP4 version of Big Buck Bunny (available for free from blender.org) and convert it to MP3, using ffmpegs default settings:
Code:
ffmpeg -i big_bug_bunny_480p_surround-fix.avi test.mp3
Slackware 32 bit: 38 seconds
Slackware 64 bit: 33 seconds

Though the advantage of 64 bit doesn't look that much, keep in mind that this is running on a quite powerful CPU, so numbers on a less powerful machine (like the OP's Atom) might look different, where the extended features can make more of a difference.

My conclusion: On slower CPUs 64 bit might well be worth it, even with the increased usage of RAM (which is not anywhere near to double the amount of 32 bit), depending on what you plan to do with the machine. For "normal" day-to-day usage differences are not significant, though.

By the way, I don't think that programs like Blender, GIMP or virtualization software, which can easily reach the 4GB per-process limit, should be nuked from orbit, as I do think that not using all the registers and not using them to their full capacity is a real waste of resources. But to each its own.

@Darth Vader: You may have overlooked it, so I ask again: Which trivial tasks are it in your opinion that make multilib a necessity?
 
7 members found this post helpful.
Old 09-27-2015, 01:47 PM   #25
imitheos
Member
 
Registered: May 2005
Location: Greece
Posts: 432

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by TobiSGD View Post
Anyways, just for fun I went ahead and made a test: I installed Slackware and Slackware 64 each into their own VM (2 CPUs, 2GB RAM, 2GB swap, 10 GB ext4 /-partition, 64MB RAM for the virtual video adapter, XFCE desktop started from runlevel 3 with startx, huge kernel) and looked at the numbers.
Host hardware: AMD Phenom II X6 1055T CPU (6 cores, 2.8GHz) with 16GB DDR3-1333 RAM, tests done on a mechanical RAID 1 array formatted with BTRFS (with chattr -C for the directory that contains the disk images to prevent performance problems).
Thank you for posting this. Very nice work.

Quote:
Originally Posted by TobiSGD View Post
Let's get to a more heavy task: I installed ffmpeg (the restricted version) from AlienBob's repository in both VMs and used it to extract the audio part of the 480p MP4 version of Big Buck Bunny (available for free from blender.org) and convert it to MP3, using ffmpegs default settings:
Code:
ffmpeg -i big_bug_bunny_480p_surround-fix.avi test.mp3
Slackware 32 bit: 38 seconds
Slackware 64 bit: 33 seconds
If you have the time (and if still have the VMs of course), can you try something like x264 encoding which is cpu intensive and uses optimized asm routines ? If you run qemu you can use "-enable-kvm -cpu host" to enable your CPU's sse, avx, etc commands and run something like
Code:
ffmpeg -i big_bug_bunny_480p_surround-fix.avi -c:v libx264 -c:a ac3 -b:v 2500k -b:a 192k -preset slow -threads 2 bbb480.mp4
Edit: Also, xz is cpu intensive and uses quite a lot of memory, so compressing a 256M-512M file should be quicker in the 64bit version.

Quote:
Originally Posted by TobiSGD View Post
My conclusion: On slower CPUs 64 bit might well be worth it, even with the increased usage of RAM (which is not anywhere near to double the amount of 32 bit), depending on what you plan to do with the machine. For "normal" day-to-day usage differences are not significant, though.
In order for what Darth Vader said to happen, that is for the program to use double the amount of ram, it would need to use only data types that occupy 64bits (linux x86_64 is LP64 so pointers / longs / size_t /etc). Most programs use of course those data types but also use ints, shorts, chars, etc which remain 32bit so the actual increase in ram is what you have shown us in your test.

Last edited by imitheos; 09-27-2015 at 01:54 PM.
 
Old 09-27-2015, 02:01 PM   #26
enine
Senior Member
 
Registered: Nov 2003
Distribution: Slackware 14.2, SlackwareArm-current
Posts: 1,215
Blog Entries: 4

Rep: Reputation: 183Reputation: 183
Interesting my experience with 2G of ram was a bit different. I was on older hardware though. I found that having 3-4 tabs open in firefox and having thunderbird open as well after a while I'd start hitting swap. Didn't seem to matter what was in the tabs, it would always slow down and swap after some use.
 
Old 09-27-2015, 02:11 PM   #27
rokytnji
LQ Veteran
 
Registered: Mar 2008
Location: Waaaaay out West Texas
Distribution: AntiX 17
Posts: 5,573
Blog Entries: 20

Rep: Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652Reputation: 2652
Quote:
Memory

Chrome uses more memory than Firefox for relatively fresh starts when multiple tabs are opened, probably due to its separate-process-per-tab implementation. Firefox, however, takes longer to release memory, even when tabs have been closed[citation needed]. In older versions, Firefox would tend to consume larger and larger quantities of memory that it never released; this was termed "the Firefox memory leak", but Mozilla commentary suggests it actually was a memory fragmentation issue, which exhibits many of the same performance and resource consumption symptoms as a memory leak. Users that frequently open and close tabs may benefit from Chrome's instant release of memory for every closed tab, though Chrome does consume more memory overall.

Since Firefox 4 (current version is 38.0.5), Mozilla has fixed the memory consumption problem. Current measurements are available on Mozilla's Are We Slim Yet page.

Nowadays, Chromium (or browsers based on it) still suffer from that ugly bug which causes a big chunk of memory leak (Mar 10, 2015 it was fixed).
Grinning reading all of this on my I5 Dell E4310 with 8 gig of ram, 60 gig SSD, running a 32 bit iso.
With a older kernel also. Just cuz I can. My 64bit cd had a bad burn and kernel panicked on boot.
So being in a hurry. I went with my 32 bit cd instead and a pae kernel. No regrets here on that route.
 
Old 09-27-2015, 03:36 PM   #28
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860
Quote:
Originally Posted by imitheos View Post
If you have the time (and if still have the VMs of course), can you try something like x264 encoding which is cpu intensive and uses optimized asm routines ? If you run qemu you can use "-enable-kvm -cpu host" to enable your CPU's sse, avx, etc commands and run something like
Code:
ffmpeg -i big_bug_bunny_480p_surround-fix.avi -c:v libx264 -c:a ac3 -b:v 2500k -b:a 192k -preset slow -threads 2 bbb480.mp4
Sorry, forgot to mention that in my last post, virtualization software I used is Virtualbox, host OS is Arch testing 64 bit (with multilib for Steam and Wine).
Tested your command and this is what I got:
Slackware 32 bit: 14 minutes 7 seconds
Slackware 64 bit: 12 minutes 20 seconds

Sorry, forgot to measure memory usage in this test.

Quote:
Edit: Also, xz is cpu intensive and uses quite a lot of memory, so compressing a 256M-512M file should be quicker in the 64bit version.
Tried that with an uncompressed tarball of the Slackware kernel sources (503MB), using
Code:
xz -9 linux.tar
Slackware 32 bit: 9 minutes 47 seconds, memory usage slowly went up to 879MB and pretty much stayed there (+- 5MB) while the task was running
Slackware 64 bit: 8 minutes 5 seconds, memory usage slowly went up to 902MB and pretty much stayed there (+- 5MB) while the task was running

So, in this case you trade about 20MB of memory for 1 minute 42 seconds of your time.
 
2 members found this post helpful.
Old 09-27-2015, 04:25 PM   #29
imitheos
Member
 
Registered: May 2005
Location: Greece
Posts: 432

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by TobiSGD View Post
Sorry, forgot to mention that in my last post, virtualization software I used is Virtualbox, host OS is Arch testing 64 bit (with multilib for Steam and Wine).
Tested your command and this is what I got:
Slackware 32 bit: 14 minutes 7 seconds
Slackware 64 bit: 12 minutes 20 seconds

Slackware 32 bit: 9 minutes 47 seconds, memory usage slowly went up to 879MB and pretty much stayed there (+- 5MB) while the task was running
Slackware 64 bit: 8 minutes 5 seconds, memory usage slowly went up to 902MB and pretty much stayed there (+- 5MB) while the task was running

So, in this case you trade about 20MB of memory for 1 minute 42 seconds of your time.
[irony]You must have done something wrong with the test. It can't be 20MB more. It should be another 879MB because it uses double the memory [/irony]

Thank you again for doing this.

Opinions may vary but i think 2 minutes less in 14 minutes (12% less) is not a negligible difference. Of course this speed increase happens only on certain programs and not on everything. But the point is that 64bit is not slower and certainly doesn't waste half the resources.
 
Old 09-27-2015, 04:37 PM   #30
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860Reputation: 4860
Quote:
Originally Posted by enine View Post
Interesting my experience with 2G of ram was a bit different. I was on older hardware though. I found that having 3-4 tabs open in firefox and having thunderbird open as well after a while I'd start hitting swap. Didn't seem to matter what was in the tabs, it would always slow down and swap after some use.
Thought about this for a while, then decided to test it, so I started the 64 bit VM, opened Firefox with 3 rather heavy tabs (Youtube with a video running, my Facebook profile and a Google image search for Slackware) and KMail (Thunderbird somehow has difficulties with my mail server setup and won't connect), which imported about 15.000 mails (1.3GB) from my main account. Memory usage is now settling around 920-950MB, with swap untouched, will let it run for a while and see what happens.
If this doesn't change it might be that you ran into a memory leak that is not present in the 32 bit version of whatever program was causing this (Thunderbird?).

Edit: Did the same in the 32 bit VM and ended up with about 120MB less RAM used. While this is significant, it doesn't explain why you hit swap with your setup on 64 bit, so I believe this indeed may have been caused by a bug. Of course without testing on your side this is just speculation.

Last edited by TobiSGD; 09-27-2015 at 04:49 PM. Reason: added info
 
  


Reply

Tags
choice, netbook, slackware


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
[SOLVED] Slackware current x64 and KDE doesn't start? hsahin4 Slackware 6 02-02-2011 03:00 PM
Slackware current x64 dbus related issue kkmic Slackware 2 12-15-2010 04:37 AM
libelf.so.0 not found slackware-current x64 luckyknight Slackware 2 10-22-2010 12:38 PM
NDISwrapper works for Slackware 13.0 x86 but not Slackware 13.0 x64 - Belkin F5D8053 thewizkid Slackware 0 01-14-2010 07:18 AM
Slackware-Current x64 & x86 + Nvidia SqdnGuns Slackware 7 05-24-2009 11:34 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 08:44 PM.

Main Menu
Advertisement
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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration