Disadvantages of running 32bit on 64bit Hardware

What are the disadvantages of installing the 32bit version of Suse11.1 on new 64bit Hardware?

I currently run 64bit Suse 11.1 KDE4 on my new Dell Precision M4400 Laptop. This is my machine that I use for work, so it should be stable, but there are numerous problems. :frowning:

So I think about reinstalling 11.1, 32bit with KDE3 again.

While most crashes and problems are likely due to KDE4, I also have trouble using Java, since there is no 64bit browser-plug-in in the repositories for Sun-Java and I resort using OpenJDK due to other troubles.

Since I need the Java-plugin for work occasionally, I currently resort to Windows for these task now, which is very disappointing, since it all worked fine using Suse 10.3 on my old laptop. :frowning:

You will probably find things generally work better using 32bit. Certainly some aspects of Java.

There are no real disadvantages - But you start to benefit from _64 duel core’s when you have 4GB+ RAM

I do have 4GB (well, 3.85GiB) for this IntelCore2Duo T9400.

So will I be still fine with 32bit?
Won’t it slow down things?
Won’t the problems with the laptop’s devices?

Is there a way to switch without a reinstall? (I do have separate root/home partitions anyway.)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To be overly critical dual cores have nothing to do with it. Having > 4
GB RAM in your system will be best-utilized with a 64-bit box regardless
of the processors involved.

The biggest disadvantage I can think of for running 32-bit on 64-bit
hardware is… you have 64-bit hardware. You will not get full
performance out of it (potentially increased performance when doing
numeric calculations with high-precision or large numbers) unless you
utilize all for which you have paid. Still, while I consider 64-bit
completely ready for prime time, some people have experienced problems
as mentioned, though I think most of them have been overcome. My SLED
10 SP2 x86_64 system that I use for everything doesn’t have any problems
at all with Java/Flash/networking/etc. so I can’t complain.

Good luck.

caf4926 wrote:
> You will probably find things generally work better using 32bit.
> Certainly some aspects of Java.
>
> There are no real disadvantages - But you start to benefit from _64
> duel core’s when you have 4GB+ RAM
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJkDcF3s42bA80+9kRAluOAJ9OF2YabJ7cLBsxmz3nrC3X07ul3gCdET2D
vLdwIYe9TF9EwvfqfOuPMKQ=
=ds2b
-----END PGP SIGNATURE-----

STurtle wrote:

>
> WHAT ARE THE DISADVANTAGES OF INSTALLING THE 32BIT VERSION OF SUSE11.1
> ON NEW 64BIT HARDWARE?
>
> I currently run 64bit Suse 11.1 KDE4 on my new Dell Precision M4400
> Laptop. This is my machine that I use for work, so it should be
> stable, but there are numerous problems. :frowning:
>
> So I think about reinstalling 11.1, 32bit with KDE3 again.
>
> While most crashes and problems are likely due to KDE4, I also have
> trouble using Java, since there is no 64bit browser-plug-in in the
> repositories for Sun-Java and I resort using OpenJDK due to other
> troubles.
>
> Since I need the Java-plugin for work occasionally, I currently resort
> to Windows for these task now, which is very disappointing, since it
> all worked fine using Suse 10.3 on my old laptop. :frowning:
>
>
I think that there now is a 64bit browser plugin
http://java.sun.com/javase/6/webnotes/6u12.html

Suse 11.1 x64, Kde 4.2beta, Opera 10.x weekly

[QUOTE=google01103;1941739]STurtle wrote:

I think that there now is a 64bit browser plugin
Java SE 6 Update 12 Release Notes.
Yes, I did see that, but since there is still no SUSE repository containing it, then there a likely troubles (at least in my past 5 years Suse experience, but then again I am a point-and-click-and-never-outside-yast-user).

There is a thread here that annouces the availability in November2008, followed by problem reports, etc.

I was using _64 for the last couple of years and managed fine. But now I’m using 32bit. I can’t see any real drop in performance. But I only have 2GB RAM. I do quite a bit of encoding too, but still get good performance.

Considering that an install takes about 30mins. And if you can download the dvd .iso easily - Just try it and see.

Your kernel choice of course for 4GB should default to PAE. Just FYI.

caf4926 wrote:

> But I only have 2GB RAM.

Wonderful how we just toss around phrases like that these days. When I
started programming 31 years ago, our super-computer had one whole MiB. And
I think it cost about a pound a byte. Mind you, it was upgraded a year or
two afterwards to a massive 2MiB.


Graham P Davis, Bracknell, Berks., UK. E-mail: newsman not newsboy

:open_mouth:

How do I exactly do that? If I click on kernel-pae in YAST->Software, I get all sorts of messages until it deselects kernel-pae again. Searching for PAE at en.opensuse.org does not seem to give useful results. :frowning:

Will I still need this if I indeed switch to 32bit?

You won’t notice too much in normal use, which will often depend on disk access and such.

I think it makes sense, to try to install KDE 3 on the 64 bit first, and see if issues are due to KDE 4 / video issues.

I found -pae kernels pretty pointless unless you have large memory graphics card. The difference on a few 100 KiB in 4 GiB is just too small.

Can’t the Java plugin use 32 bit, like with Adobe Flash which provides nice insulation of Browser against the plugin crashing as it runs in a different process.

Stumbled on this about the Java under 64 bit openSUSE at Planet Finally: 64 bit Java Browser Plugin from Sun

Looks like installing a 32 bit browser was a work round previously.

I’m not sure _64 isn’t a dead end… I mean, as long as an integer is 32, that is.

I run 32-bit on a _64 machine and it is a lot simpler to find drivers, etc. for new hardware items. I don’t have to work-around or use experimental flash or any of that nonsense.

I don’t even notice a difference in performance between 32 and 64, so if I’m giving up something, I consider a fair trade.

What experimental flash? We are using the same flash plugin as everybody else, thanks to nspluginwrapper. When the 64-bit plugin is stable, we can use that too. Things have changed. Get up to date.

I am also considering 32 bit (and i do have 8GBmemory), i also didn’t encounter any performance issues but again, i’m just an average user.
What i do like with 32 bit is that You don’t need any compatibility packages and since ext3 is really horrible with small files i consider it a downside to install 32 bit packages. And since most of the world still runs on 32 bit then it’s the right way to go (for now) but i remember many threads if someone should choose 32 or 64 bit rotfl! Until developers of most apps won’t “force” 64 bit versions to be made first then we will have to live with being “worse” :wink:

About that experimental flash :slight_smile: It’s more stable being an alpha release than the stable 32 bit release in nspluginwrapper :wink:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keep in mind to take advantage of a full eight GB RAM you need the PAE
kernel which imposes a performance hit by default (unavoidable
regardless of the platform you use). Having a few hundred megabytes
(potentially) of 32-bit libraries will probably cause less loss than
using PAE unless you’re using a really poor filesystem, and there will
probably be a need to support both architectures in 64-bit-land for a
few years yet while everybody makes the move.

Good luck.

BenderBendingRodriguez wrote:
> I am also considering 32 bit (and i do have 8GBmemory), i also didn’t
> encounter any performance issues but again, i’m just an average user.
> What i do like with 32 bit is that You don’t need any compatibility
> packages and since ext3 is really horrible with small files i consider
> it a downside to install 32 bit packages. And since most of the world
> still runs on 32 bit then it’s the right way to go (for now) but i
> remember many threads if someone should choose 32 or 64 bit rotfl! Until
> developers of most apps won’t “force” 64 bit versions to be made first
> then we will have to live with being “worse” :wink:
>
> About that experimental flash :slight_smile: It’s more stable being an alpha
> release than the stable 32 bit release in nspluginwrapper :wink:
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJkZpX3s42bA80+9kRArq4AJ9eAJ9+gm8N2qYvfJOa4lB/CCGqRACeLDYc
NOxYH1tyCFp067sGCZUf1JY=
=OxNu
-----END PGP SIGNATURE-----

I understand everyone says that there is a performance hit when using 32 bit kernel with PAE but for now i haven’t felt any downsides. Recently i was encoding 10 movies at once on C2Q (32 bit PAE) and i had no real problems with performance. Maybe if i would run benchmarks then there might be a slight difference in favour of 64 bit version but as i say, i’d need to see some benchmarks.

lol, if you are encoding movies, you really should consider using 64bit as both Xvid 1.2 and x264 are faster, in case of x264, up to 15% compared to the 32bit version

Ehhh, faster, better stronger, reminds me of drag races and big kids showing off :slight_smile: I don’t care about the speed :wink:
If i would then i would have the i7 Intel CPU and nothing to eat lol!
As i said, i’m just an average user so i won’t really see any differences. I’ll try 64 bit again with 11.2 until that time 32 bit it is :slight_smile: If you say that there is such performance increase then i’ll look for it just out of curiosity.

Not only I say it, but it’s also been confirmed by the x264 devs themselves (Dark Shikari and pengvado), the doom9 forum and many other places. Fact is, x264 is ~15% faster on 64bit linux

It may be because x264 uses those additional registers where other apps might not use them so it’s probably just x264 and other media en/decoding apps (heavy use of registers? ). Otherwise i bet there are no advantages though i’d like to see a 64 bit system compared with a 32 bit PAE hmmm.
I’ll ask for such benchmark at phoronix, maybe they’ll make some benchmarks, that would be great to see this.