Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance

[discordian]

Hm. Then how do people even get that thing to install? The last Ubuntu release to include ia32-libs was Raring. On Debian Wheezy 64-bit, ia32-libs depends on ia32-libs-i386, which isn't available for installation.

I dont know about Ubuntu, but on Debian Wheezy and up, the packet-manager will resolve 32-bit depencies, so you dont need ia32-* wrapper, the libs just come from the 32-bit repository (if you enabled 32bit).

64bit is nice if its pure, if you run some 32bit-only software you have the same libraries multiple times. For that reason I usually use 32bit installations on PCs with <2GB, and especially if the use shouldnt bugger me with questions why some old binary stuff doesnt run because of the missing 32bit-libs.

[steveriley]

Using 64-bit Kubuntu 14.10, I tried an experiment this evening:

steve@t520:~$ [B]sudo dpkg --ignore-depends=ia32-libs -i google-earth-stable_current_amd64.deb[/B]

Then:

steve@t520:~$ [B]google-earth[/B] 
[1027/223157:ERROR:net_util.cc(2195)] Not implemented reached in bool net::HaveOnlyLoopbackAddresses()
[1027/223157:ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.
.
.
{repeated many times}
.
.
Another crash happened while handling crash!

Notably, ~/.config/Google and ~/.googleearth were created and populated.

Running a second time resulted in the same errors appearing in the console window but it didn't crash. I zoomed around the planet for four or five minutes with no problem.

However, third and subsequent runs all failed. I deleted those subdirectories and ran it again. This time, the first run was fine. A second run failed. A third run was fine. So it's really hit-or-miss here, which is so totally weird. All failures are like what I indicated above.

Once more I deleted the directories. This time, after taking a look at the shell script that /usr/bin/google-earth links to, I ran:

steve@t520:~$ [B]LD_LIBRARY_PATH=/opt/google/earth/free /opt/google/earth/free/googleearth-bin[/B]

The first run crashed. Subsequent runs all seemed fine. I'm not exactly sure what to make of this, other than that forcing the binary to use Google's supplied libraries makes it appear to be more stable. It's still rather a mystery as to why any 32-bit libraries may be needed with the 64-bit executable.

BTW, it sure made my laptop get quite hot!

[caligula]

I hardly use windows, but my only win box runs win 8 pro 32-bit version. Microsoft hasn't dropped 32-bit yet.

Any linux box I build with under 2.5 GB RAM goes with 32-bit OS. 32bit x86 is quite a bit more memory and CPU cache efficient than x86_64; too bad about the extra registers and the newer instructions, and that x32 ABI is no longer being developed. (At 2.5 G RAM it's a toss up, the last one I build got Mint 17 32-bit.)

The benchmarks showed generally 32-bit underperformed; in my opinion, it doesn't look like this was by a very substantial amount, except in a few rare cases--which I don't know how often something like that occurs in real life common computer usage.

With a regular performance machine that has a few gigs of memory, I agree, in the future the OS itself should move to x86_64, yet I believe 95% of the applications and subprocesses should be running in 32-bit to conserve memory and cache bandwidth. (Just iimagine 64 bit flash plugins running on all your opened webpages. It already hogs enough memory bandwidth under 32-bit execution; it has the potential to suck twice as much in _64.)

There should be a handful of applications that are running in 64-bit mode; namely, apps where performance matters and where performance is actually substantially improved by running it in _64 extensions, and user compiled code where the user chooses to compile and run in 64 bit mode.

If you compile 32-bit apps using latest SSE optimizations and native arch sheduling etc., it shouldn't be that much slower than 64-bit. Especially with PAE disabled. 64 bits only helps if you need large integers and those registers. You already get full SSE1-3 support with 32bits. The extra registers won't double the performance. There's the law of diminishing returns and using an efficient register allocation strategy in compiler helps a lot.