LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Speed difference between 32 and 64 bits (http://www.linuxquestions.org/questions/slackware-14/speed-difference-between-32-and-64-bits-4175419451/)

arodlinux 07-30-2012 08:00 PM

Speed difference between 32 and 64 bits
 
I got an 64 bit capable machine with 6 Gb of RAM and I wonder if I should install 64 instead of 32 bit version. Is the difference is speed noticeable? The only thing is that I need 2 programs that will run in wine and I don't know is will be worth the "trouble" of getting wine installed to work under 64 bits.

jefro 07-30-2012 08:16 PM

I almost doubt you could see the difference. You might feel it is faster but the difference wouldn't be much. Large cpu time apps would tend to show it or servers running for hours tend to really show it.

I'd wait until you have to major issue and have to reload unless you are really lacking things to do.

ReaperX7 07-30-2012 08:20 PM

It's very minimal if you run native 64-bit applications, but 32-bit software can see slight improvements at times. However, native 64-bit programs will have a larger memory footprint and may seem to run slower, but again it's very minimal.

However, the real issue is how much of the system resources do you want to utilize. Basically... If you run 64-bit capable hardware, you should run a 64-bit OS.

BrZ 07-30-2012 09:21 PM

I can be wrong, but to use your full 6GB of RAM you'll need 64-bit.

animeresistance 07-30-2012 09:27 PM

Well it depends on how you will use your hardware and what you want to run on it.

If you are going to make a lots of heavy math, engineering tasks, you should use 64 bit (and of course if you want to use the 6 GB of memory). If you will not do heavy tasks, i think 32 bit will ok. But again, it depends of what do you want to run on your hardware

Cheers :)

markush 07-31-2012 01:06 AM

Quote:

Originally Posted by ReaperX7 (Post 4741730)
It's very minimal if you run native 64-bit applications, but 32-bit software can see slight improvements at times. However, native 64-bit programs will have a larger memory footprint and may seem to run slower, but again it's very minimal.

The memory will be no problem with 6GB of RAM. At least the memory-footprint will not compensate the advantages of a 64bit system (if any).
Quote:

Originally Posted by BrZ
I can be wrong, but to use your full 6GB of RAM you'll need 64-bit.

The 64bit-kernel uses the whole 6GB of RAM, but you can use a PAE-kernel with the 32bit-system. The PAE-Kernel can use the whole amount of RAM. You would only have to rebuild your kernel and configure in "Processor and Features" for "more than 4GB of RAM".
The difference is that with a 32bit-PAE-kernel each process can use a maximum-amount of 3GB of RAM whereas the RAM per process on a 64bit-system is not limited.

Markus

damgar 07-31-2012 01:27 AM

I think Slackware now uses a PAE kernel by default.

Mark Pettit 07-31-2012 02:31 AM

If you're worried about the 2 wine programs, then install AlienBob's multi-lib system. I also run 2 programs under wine and they work perfectly fine. Point is that if you have a 64bit cpu, then you may as well use the features fully. And being able to run virtual machines under that of ANY size is handy too.

H_TeXMeX_H 07-31-2012 03:02 AM

You can see a noticeable performance increase with even 2GB of RAM. With 6GB I would say 64-bit is a must. You can see the difference even in the installer, which is almost twice as fast on 64-bit.

The difference usually is greatest for number crunching apps like compression, encoding, scientific, etc. Every program is slightly faster or a lot faster in 64-bit, so overall you can notice the difference in speed.

Benchmarks:
2009
http://www.phoronix.com/scan.php?pag...u_32_pae&num=1
2012
http://www.phoronix.com/scan.php?pag...204_3264&num=1

guanx 07-31-2012 10:08 AM

Quote:

Originally Posted by H_TeXMeX_H (Post 4741967)
... You can see the difference even in the installer, which is almost twice as fast on 64-bit. ...

Amazing! How is it measured?

H_TeXMeX_H 07-31-2012 10:20 AM

Quote:

Originally Posted by guanx (Post 4742206)
Amazing! How is it measured?

With a stopwatch, or maybe just a regular clock.

ReaperX7 07-31-2012 04:30 PM

From experience... about ever 2GB or RAM you add you can shave off about 1 minute or so from the install, but as always a faster multi-core CPU will shave off more. However the main issue you will always have is the transfer rate of your disk controller.

Mercury305 07-31-2012 07:18 PM

Quote:

Originally Posted by arodlinux (Post 4741722)
I got an 64 bit capable machine with 6 Gb of RAM and I wonder if I should install 64 instead of 32 bit version. Is the difference is speed noticeable? The only thing is that I need 2 programs that will run in wine and I don't know is will be worth the "trouble" of getting wine installed to work under 64 bits.

it will be a huge difference. Slack runs quite will with 64.

foobarz 07-31-2012 07:30 PM

no real reason not to run slackware64
 
I am on slackware64 with the multilib packages. I have encountered no problems running any 32bit program. Same thing with Windows 7 - no reason on modern hardware with 4+ GB ram to not install the 64bit Windows 7. You can run 32bit programs too without problems so far as I know.

The only problem with running multilib is upgrading it. You have to follow alienbob's instructions to get started, where you are running 13.37 or -current and use the multilib for the one you are running.

Once you have it setup initially, then when you upgrade your 64bit packages, the 32bit compat32 versions do not match anymore. So, you have to upgrade those 32bit compat32 packages separately. Maybe you are able to rsync or lftp mirror alienbob's multilib/13.37 or multilib/current directory, and use upgradepkg * in each directory if his collection is up-to-date.

You have to make sure that during your regular upgrades that you blacklist packages gcc* and glibc* because those are special multilib versions that you have to manually upgrade from alienbob's site when new versions of them are available.

Another way to upgrade the 32bit compat32 packages is to mirror both the slackware-current and slackware64-current (assuming you are using -current) using mirror-slackware-current.sh script which can be found at
http://alien.slackbook.org/blog/local-slackware-mirror/ .
You can edit this script so it doesn't build the install-dvd each time.

With a mirror of both, you setup slackpkg to use your local mirror of slackware64-current to get upgrades. You upgrade your 64bit packages like normal after you have a up-to-date mirror.

Then you can use the convertpkg-compat32 script, which you should have installed already following alienbob's multilib install instructions, to convert an individual normal 32bit package into a package-compat32 that you install/upgrade with. This process can be automated using a script you can write that could be something like this (that I have used):

Code:

#!/bin/bash
# Upgrade installed compat32 packages from 32-bit slackware-current packages.
#
# The default is to do a dry run that doesn't do anything.
# Pass --go on the command line to do the real stuff.
# Still, nothing happens unless you okay it at prompts that show pending commands.
#
# For each installed pkg *-compat32-* in /var/log/packages:
#  Get installed pkg info.
#  Find current pkgname in /home/user1/mirror/slackware32/
#  Get current pkg info.
#  Get pkgset directory letter/name.
#  If version or build is different:
#  Prompt to ask to upgrade. If yes:
#    convertpkg-compat32 on current pkgname.
#    upgradepkg on the resulting /tmp/pkgname
#    remove pkg in /root/packages-multilib/<set>-compat32/pkgfile
#    mv /tmp/pkgfile /root/packages-multilib/<set>-compat32/

ARCH=${ARCH:-$(uname -m)}

# Location to find 32-bit slackware-current package set directories <set>/
MIRROR32=/home/user1/mirror/slackware32/slackware-current/slackware
# Location to store 32-bit slackware compat32 package set directories <set>-compat32/
MULTILIB=/root/packages-multilib/compat32
# Warning: spaces in path/filenames would cause problems with the CMD variables below

# Collect package name/filename of all packages under $MIRROR32 into associative array CURRENTPKG:
#  CURRENTPKG[<package name>]=<./set/filename>
# Used later to find slackware-current package filename associated with a package name.
echo "Collecting slackware-current package information..."
declare -A CURRENTPKG
for i in $( cd $MIRROR32 && find . | grep ".*\.t[xg]z$" ) ; do
 PKGFILE=$( basename $i )
 PKGNAME=$(echo $PKGFILE | rev | cut -f4- -d- | rev)
 CURRENTPKG[${PKGNAME}]=${i}
 #echo "PKGFILE=$PKGFILE"
 #echo "PKGNAME=$PKGNAME"
 #echo "${PKGNAME}=${CURRENTPKG[${PKGNAME}]}"
done

echo "Searching for upgrades..."
# For each installed compat32 package, look for new current version and upgrade
for i in /var/log/packages/*-compat32-* ; do
 # Collect info about installed compat32 package
 PKGFILECOMPAT=$(basename ${i})
 PKGNAME=$(echo ${PKGFILECOMPAT} | rev | cut -f5- -d- | rev)
 PKGVERSION=$(echo ${PKGFILECOMPAT} | rev | cut -f3 -d- | rev)
 PKGBUILD=$(echo ${PKGFILECOMPAT} | rev | cut -f1 -d- | cut -f2- -d. | rev)
 # Collect info about 32-bit slackware-current package
 if [ -z ${CURRENTPKG[${PKGNAME}]} ] ; then
  echo
  echo "Package: ${PKGNAME}, is NOT in slackware-current; unable to find upgrade."
  echo " Installed: ${PKGFILECOMPAT}"
  echo " This package may have been installed special, or it has been removed from slackware-current."
 else
  CURRENTPKGFILE=$(basename ${CURRENTPKG[${PKGNAME}]})
  CURRENTPKGNAME=$(echo ${CURRENTPKGFILE} | rev | cut -f4- -d- | cut -f1 -d/ | rev)
  CURRENTPKGVERSION=$(echo ${CURRENTPKGFILE} | rev | cut -f3 -d- | rev)
  CURRENTPKGBUILD=$(echo ${CURRENTPKGFILE} | rev | cut -f1 -d- | cut -f2- -d. | rev)
  CURRENTPKGSET=$(echo ${CURRENTPKG[${PKGNAME}]} | cut -f2 -d/ )
  if [[ (${PKGVERSION} != ${CURRENTPKGVERSION}) || (${PKGBUILD} != ${CURRENTPKGBUILD}) ]] ; then
  # Package upgrade is available
  echo
  echo "Package: ${PKGNAME}, available in slackware-current."
  echo " Installed: ${PKGFILECOMPAT}"
  echo " Available:          ${CURRENTPKGFILE}"
  echo -n "Upgrade to available version? (y/n)"
  read -n 1 ANSWER
  echo
  if [[ ${ANSWER} = "y" ]] ; then
    # Prepare upgrade commands
    CMDCONVERT="convertpkg-compat32 -i ${MIRROR32}/${CURRENTPKG[${PKGNAME}]}"
    CONVERTPKGFILE="${CURRENTPKGNAME}-compat32-${CURRENTPKGVERSION}-${ARCH}-${CURRENTPKGBUILD}.txz"
    CMDMKDIR="mkdir -p ${MULTILIB}/${CURRENTPKGSET}-compat32/"
    CMDMV="mv /tmp/${CONVERTPKGFILE} ${MULTILIB}/${CURRENTPKGSET}-compat32/"
    CMDRM="rm -f ${MULTILIB}/${CURRENTPKGSET}-compat32/${PKGFILECOMPAT}.txz"
    CMDUPGRADE="upgradepkg ${MULTILIB}/${CURRENTPKGSET}-compat32/${CONVERTPKGFILE}"
    # Get permission to run upgrade commands
    if [[ $1 = "--go" ]] ; then
    echo "Performing upgrade... (warning: check pending commands before proceeding)"
    echo "Pending: ${CMDCONVERT}"
    echo "Pending: ${CMDMKDIR}"
    echo "Pending: ${CMDMV}"
    echo "Pending: ${CMDRM}"
    echo "Pending: ${CMDUPGRADE}"
    echo -n "Perform pending commands? (y/n)"
    read -n 1 ANSWER
    echo
    if [[ ${ANSWER} = "y" ]] ; then
      ${CMDCONVERT}
      ${CMDMKDIR}
      ${CMDMV}
      ${CMDRM}
      ${CMDUPGRADE}
      echo ${CMDMV}
      echo ${CMDRM}
    else
      echo "Upgrade of package aborted."
      echo -n "Continue? (y/n)"
      read -n 1 ANSWER
      echo
      if [[ ${ANSWER} != "y" ]] ; then exit ; fi
    fi
    else
    echo "Performing upgrade... dry run, echoing commands only (use --go to perform real upgrade)"
    echo "Dry: ${CMDCONVERT}"
    echo "Dry: ${CMDMKDIR}"
    echo "Dry: ${CMDMV}"
    echo "Dry: ${CMDRM}"
    echo "Dry: ${CMDUPGRADE}"
    echo -n "Continue? (y/n)"
    read -n 1 ANSWER
    echo
    if [[ ${ANSWER} != "y" ]] ; then exit ; fi
    fi
  fi
  # Upgrade done
  else
  # Package is up-to-date
  echo "Package: ${PKGNAME}, is up-to-date."
  fi
 fi
done


Basically, the script finds the installed compat32 packages, finds if there is an upgraded version available, if so converts the new 32bit package to a new compat32 package, replaces the old package in a multilib/<pkgset>-compat32 directory structure like a mirror of alienbob's multilib to keep it updated, and upgrades the package.

It seems to work, but everyone has their own way do to this. Maybe this is overly complicated, and it can be done much easier, but it works.


All times are GMT -5. The time now is 03:49 PM.