Bad performance on 64 bit, switched back to 32 bit

Ahri

This is an update from my last thread on my issues with amd64 on a core2duo laptop. I've had a lot of issues with the multitasking and eventually just gave up on 64 bit; this is after a few months of trying to fix the problem with help from the wonderful people on this forum. So, I kept some of the config files in /etc and my world file, and then blasted the system from a Gentoo boot disc, then did a stage3 x86 install and re-implanted my configs and world file. Then ran emerge -e world and got my system back up and running (after altering my previous make.conf of course).

All of this is a fairly obvious post so far, but please note that I've used the exact same setup when switching from 64->32 bit OS except for the change in make.profile and CFLAGS/CHOST. I even used the same kernel config with some minor tweaking to 32 bit settings.

So, what do I notice? An immense improvement! Multitasking now works very nicely, right now I've got a couple of emerges running (with -j3 set in my make.conf) and I can still browse the internet - how amazing is that?! Yeah that's right, it's not amazing at all, it's expected performance (now comparable with the 32bit WinXP installation I'm dual booting, fancy that), but in comparison to my amd64 setup it's _blisteringly_ fast.

I know 64 bit is the latest-and-greatest, but with all the annoyances of needing the emul-* libs and no flash (or a 32 bit flash wrapper with an apparent memory leak - which seemed worse than no flash at all to me), I seriously can't see the point in using 64 bit right now. Has anyone else had similar experiences they'd like to share? If you're getting crappy performance to the level that you actually _want_ to use windows "because it's faster" (yes, I was thinking that), I highly recommend giving 32 bit a try first. Incidentally I was advised to buy more RAM (I have 512MB), and actually considered it for a while, before mucking about on my much older desktop machine that only has a single core processor and 512MB RAM, which ran so much faster than my brand-spanking-new laptop. That's what really nudged me into switching over.

Abraxas · l33t Joined: 25 May 2003 Posts: 814

I am using 64-bit Gentoo on a Core2Duo without any performance issues at all. Multitasking doesn't slow my computer down at all. Some programs are a little slow (couple of seconds) to load but I am using PaX in the kernel, along with some other overhead-inducing kernel security options, in addition to AIGLX and compiz.

oshecho · n00b Joined: 23 Dec 2006 Posts: 62

I'm also using 64-bit Gentoo on a Core2Duo (Toshiba Satellite P100). I haven't any problems ever with performance. I can be emerging something, listening to music, and do a few other things all at the same time without any speed problems in any way.

Edit: Did you ever try to fix your DSDT? link

jonnevers · Posted: Wed Jun 06, 2007 3:21 pm Post subject:

Ahri · Posted: Thu Jun 07, 2007 9:14 am Post subject:

I've not tried an alternative DSDT (and I'd never heard of it until now), the link given by oshecho doesn't seem relevant so I guess that was a clipboard error

I checked out http://acpi.sourceforge.net/dsdt/view.php?id=704 which is the closest DSDT to mine (Satellite Pro U200-198), but I'm not sure what that would achieve; surely the DSDT used is the same in 64 and 32 bit Gentoo? Perhaps I'm missing the point...

oshecho · n00b Joined: 23 Dec 2006 Posts: 62

devsk · Posted: Fri Jun 08, 2007 7:15 am Post subject:

There is a freakishly huge thread over on amd64 forum discussing details of various kinds of slow downs people are seeing with amd64. From kernel to kernel the issue remains unsolved. And at least my patience is thinning out. I have an ultra super stable (crash wise) amd64 install with all the goodies like reiser4, suspend to ram, mythtv, vmware all working with each other fine. But the system becomes slow and mouse stutters if two disks or one disk and network get involved at the same time.

I am compiling a x86 chroot just to see if I can rid of this problem by switching to 32-bit.

moesasji · Apprentice Joined: 10 May 2005 Posts: 263

cyrxi · n00b Joined: 01 Jun 2007 Posts: 34

Just my 2 cents on the matter...

Back in November when I first got my Core 2 Duo laptop (Dell XPS M1210) I was determined to never boot windows on the machine and "get back into Linux" since things have progressed quite a bit over the past 8 years. I was originally going to try Ubuntu because of it's ease of install, but a good friend of mine pushed me towards Gentoo. I tried 64bit Gentoo and had an awful experience. It took me forever just to get X.org working and from there nothing worked - I didn't have the time or the energy to give Gentoo another shot, so I ended up going with 32-bit Ubuntu...

I am now in the process of switching over to Gentoo, but I've decided to go with 32-bit this time. For the most part everything has been relatively easy to get up and running and I'm very happy to have portage again. My system is generally a lot faster and less bloated than Ubuntu was. I'm very happy with 32-bit Gentoo except for a couple of problems, namely firefox starting slowly (which I have not tried to troubleshoot yet) and a problem with my SATA drive (which I have been pulling my hair out over).

IMO the theoretical performance gains of switching to 64-bit are not worth the extra hassle. The support just isn't there yet. When 64-bit actually becomes the "standard", then I'll probably switch over. There are just too many things that are buggy at the moment, and I've never heard anyone say "Oh my god, I switched to 64-bit and everything is SO much faster".

devsk · Posted: Fri Jun 08, 2007 8:36 pm Post subject:

Actually, the most gains are in multimedia processing, be it faster encodes or better video with mythtv in HD. If you are not into multimedia big time, there is no reason to go 64-bit. In fact, you lose disk space (pkgs compile to smaller size on 32-bit systems) and require more RAM (remember a memory reference, a pointer in C, will need twice the memory, 8 bytes instead of 4, in 64-bit system) to run 64-bit system.

Another possible scenario is a big server where you want to install >64GB of RAM. Although thru highmem, there is support for upto 64gb, even for systems requiring > 4gb, you might want to jump to 64-bit because 32-bit support for highmem is little slower than native 64-bit.

Cyker · Veteran Joined: 15 Jun 2006 Posts: 1746

TBH the increases are pretty trivial given todays wastage (I was thinking that this '500GB' drive is short of more space than all the drives I've owned up to my Athlon 800!)

64 bits seems stable enough for mainstream use of source-only stuff, but IMHO if you:
1) Don't have any hangups about running the CPU it in Protected mode instead of Long mode ("I'm only using half my CPU! Oh noes!!")
2) Don't do anything involving more gigs of RAM than anything but server boards can currently support (While 64-bit CPUs can linearly address many gigs of RAM, most mobos can't even use more than 3-4GB due to BIOS limitations and legacy address space issues.)
3) and aren't doing anything that does nothing but crunch ridiculously big numbers (I'm sorry but video encoding and archiving don't really count - While theoretically faster, every test I've seen has put 64-bits only marginally ahead. The only area where it's trounced 32-bits in benchmarks convincingly is encryption, which as we all know is only used by criminals! and pirates! <s>)

... then 64 bits will convey you pretty much no advantages at all other than bragging rights to mock people like me (A pretty lame reason) and encourage more coders to make their softs 64-bit clean (A much better reason!)

64-bits is still primarily used by academics and/or people that would rather write code for Suns (which have much less brain damaged architecture) but can't afford it or need SIMD and more processing power than most high-end Suns can provide.

Being able to write a quick and dirty bit of code which loads your entire set into RAM instead of having to write elegant code to work on bits of it at a time is a much favoured RAD coding technique often used by CS students

Sorry for the long post(s). I don't know why I keep finding myself compelled to jump into these arguments because, truth be told, I really don't care either way!! :shock:

So apologies again...

devsk · Posted: Sat Jun 09, 2007 6:12 pm Post subject:

devsk · Posted: Tue Jun 12, 2007 7:56 pm Post subject:

cheater512 · Posted: Tue Jun 12, 2007 11:33 pm Post subject:

Could be a Intel thing because I've never experienced any problems with my AMD box.
I have abused it pretty badly too.

All in all there is very little difference between 64 and 32 for me.

devsk · Posted: Wed Jun 13, 2007 3:05 am Post subject:

have a look at the thread at:

https://forums.gentoo.org/viewtopic-p-4101407.html#4101407

Because I have two parallel installs of amd64 and x86 with kernel and same packages, I made some benchmark comparisons. See which performs better for yourself.

moesasji · Apprentice Joined: 10 May 2005 Posts: 263

devsk · Posted: Thu Jun 14, 2007 2:16 pm Post subject:

moesasji · Apprentice Joined: 10 May 2005 Posts: 263

OK, update....faster then expected.

I've now tried all my usual torturing techniques on my system. As far as I can tell the problem(s) that I experience when running ~AMD64 are not present with ~x86. I can now simultaneously calculate an iso-image with K3B, extract a big-archive and calculate a checksum with par2cmd and I the system still remains responsive.

So switching to ~x86 is indeed the way to solve this extremely annoying bug..... :evil:

darkphader · Veteran Joined: 09 May 2002 Posts: 1225 Location: Motown

No problems here with 64bit:
http://realcomputerguy.com/files/tcg_desktop.avi

Chris
_________________
WYSIWYG - What You See Is What You Grep

sonicbhoc · Posted: Thu Jun 14, 2007 6:12 pm Post subject:

No real issues aside from X stability at certain times. Some GLX-based games lock up X completely, and sometimes while switching VTs and shutting down, the entire computer locks up and I have to power off without shutting down. I'm too lazy to see if I have the problem in x86, and the problem isn't that bad anyway.
_________________
I'm too lazy to keep this stupid signature up to date, so here's something more interesting:
My friend Hetdegon can draw if you ask me.
Now using PClinuxOS on my laptop and Gentoo on my desktop and new laptop.

devsk · Posted: Thu Jun 14, 2007 6:36 pm Post subject:

devsk · Posted: Thu Jun 14, 2007 6:39 pm Post subject:

sonicbhoc · Posted: Thu Jun 14, 2007 7:26 pm Post subject:

dirk_salewski · Posted: Mon Jul 02, 2007 9:36 pm Post subject:

Hello NG,

I have serious problems with my amd64-install too. I just didn't realize for two years

Recently the old Pentium II of my father-in-law crashed (he had still been running Windows 98 on that old typewriter). Well, I decided to give him my second PC (which was running Windows XP for website testing purposes and became obsolete with ies4linux, qemu and the like). Since I wanted to keep my WinXP for occasional gaming (AoE III), I installed Ubuntu 32bit on my second PC.

Some figures now: My "real" machine is an AMD Athlon64 3.200+, 1GB 2.2.2-RAM, Via K8T800-Chipset, Samsung-PATA. The "second" one is an AMD Sempron 2.200, 512MB el-cheapo-RAM, nForce-Chipset, Excelstor-PATA.

One would think that, since the "real" machine has computing power x 1,5 and RAM x 2 (and only carefully, hand selected components), it would be faster, lots faster.

The second one boots in a fraction of the real.
The second one fires up firefox in about half the time. I consider calling it snorefox on the real.
The second one starts OpenOffice.org within seconds. The real one - well, I usually have time to jot down the management summary on paper before it comes up.

Could it be that all the "first-generation"-chipsets for AMD64 were - hm - drafts or something? Or is it a 32vs64-issue. I'm gonna install 32bit-Ubuntu on my real machine now and issue some "times", then report back. That 64bit-crap-install isn't gonna survive the next weekend.

Greetings,

Dirk
_________________
Egal was Du kochst: Karl Marx.