# 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

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

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

 *oshecho wrote:*   

> 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

 

same on my amd64. i'd never recommend 32bit over 64bit for any reason, then again it doesn't particularly matter one way or the other. except maybe in the case of the OP.

----------

## Ahri

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  :Wink:  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

 *Ahri wrote:*   

> 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...

 

Hehe, sorry about the wrong link. Here is the correct one: https://forums.gentoo.org/viewtopic.php?t=122145. Having a buggy DSDT can cause ACPI problems. So I'm guessing that fixing it might solve your problem. Although, since your laptop works fine in 32 bit, I'm not sure how likely it is the problem. At the very least, by fixing it your computer will be better off, even if you stay with 32 bit Gentoo. I ended up fixing mine myself because I couldn't find exact match that was done already (the BIOS version needs to match, mine was newer).

So I suggest that you fix your DSDT and then whether or not you try 64 bit Gentoo is up to you. If you need help, I'll do my best to help.

----------

## devsk

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

 *devsk wrote:*   

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

 

I'm really glad you are going to test that as that problem on AMD64 is driving me nuts.   :Shocked: 

However I could not find the time (or motivation) to test that option.....

----------

## cyrxi

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

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

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  :Wink: 

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!!  :Shocked: 

So apologies again...

----------

## devsk

 *Cyker wrote:*   

> ... 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) 

 ...  :Laughing:  who mocked you Cyker? I find people bragging about amd64 very silly. Having said that I did notice a difference in encoding speed using mencoder by 15-20% when I compared them a year ago and made the switch. 15% is a lot of money because 100% cpu usage (result of encoder running) translates directly to electricity bill. If this box didn't have the tv tuner and mythtv, I would have not switched.

Apart from that, your points are valid, and there is no reason for anybody to mock you.

----------

## devsk

 *moesasji wrote:*   

>  *devsk wrote:*   I am compiling a x86 chroot just to see if I can rid of this problem by switching to 32-bit. 
> 
> I'm really glad you are going to test that as that problem on AMD64 is driving me nuts.  
> 
> However I could not find the time (or motivation) to test that option.....

 Alright, this option has been tested and 32-bit install with the exact same copy of the kernel source and .config (sans the options which don't exist for x86), doesn't exhibit the freezes seen with amd64. It is much smoother and I am staying with x86 for now. I have updated the bug and the other thread with this info.

moesasji, I would suggest using an x86 livecd and boot into a 2.6.21 kernel. And then mount your FSs and do your usual tests to see if your freezes reproduce.

----------

## cheater512

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

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

 *devsk wrote:*   

> 
> 
> moesasji, I would suggest using an x86 livecd and boot into a 2.6.21 kernel. 
> 
> And then mount your FSs and do your usual tests to see if your freezes reproduce.

 

Sorry for not replying...I was quite busy with other stuff. 

Anyway seeing the results of your switch from AMD64 to x86 I already installed ~x86 within a chroot and have booted into it. Unfortunately my test is not that clean as I moved HD's from my server to the desktop at the same time (lack of HD-space on the desktop). Moreover the x86-root(kernel 2.6.21) is on a different drive with JFS, while the AMD64-root(kernel 2.6.22-rc3) is on ext3. Unfortunately I did not take great care during kernel-config to keep them as identical as possible. But can always compare later-on to spot the differences. I can boot in both x86 as AMD64 as well to be able to compare.

The quick and dirty bonnie++ test already seems to indicate that the x86 behaves much better also in my case. It is clearly not completely starved as happens in the AMD64 case. Realtime for AMD around 1.5minutes while x86 reports ~0.055s something like that. 

I still need to install K3B to perform my usual tests and see if the problem is indeed gone under x86.

I will report back what I find...but it might take a couple of days. 

ps) Note that overall the UI with the 2.6.22 kernel feels more responsive than the 2.6.21, so it is easy to misinterpret things.

----------

## devsk

 *moesasji wrote:*   

> 
> 
> ps) Note that overall the UI with the 2.6.22 kernel feels more responsive than the 2.6.21, so it is easy to misinterpret things.

 that's because some of the defaults for sys.vm.dirty* have been adjusted in 2.6.22. But my switch and tests were all done on 2.6.21. I couldn't get 2.6.22 to do all the reiser4/vmware/suspend-to-ram thing. So, gave up on it.

----------

## moesasji

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 or Very Mad: 

----------

## darkphader

No problems here with 64bit:

http://realcomputerguy.com/files/tcg_desktop.avi

Chris

----------

## sonicbhoc

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.

----------

## devsk

 *sonicbhoc wrote:*   

> 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.

 your computer locks up and you have no real issues? You have a very forgiving nature.

I agree amd64 has its advantages and all (I even started a separate thread comparing the two and amd64 wins benchmarks, and some it wins handsomely), but nobody deserves a system that encodes mpeg faster and creates a livecd real quick but freezes from time to time.

----------

## devsk

 *moesasji wrote:*   

> 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.....    

 Ok, this is great! I am not hallucinating....  :Very Happy: 

Can you please update the bug? It will help bump the bug and some more people might be interested. Meanwhile, I create a diff (should be small because I reused amd64 .config) between the two .configs and attach to bug. When I reach home after work.

----------

## sonicbhoc

 *devsk wrote:*   

>  *sonicbhoc wrote:*   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. your computer locks up and you have no real issues? You have a very forgiving nature.

 

Yeah, but I don't play games or shut down very often. Most of the times, unclean shut downs come from me forgetting to charge the battery and it runs out.

----------

## dirk_salewski

Hello NG, 

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

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

----------

