I have a 64-bit computer but 64-bit distros have been giving me huge problems when using 32 bit apps or trying to install 32-bit libraries, so I think I'm going to just switch to 32 bit. Will I notice much of a hit in performance? This computer is mostly used for web and games, nothing particularly cpu-intensive (no graphics rendering, etc)

If by "games", you mean flash-based games or solitaire or similar, then no, you won't notice a difference. 64-bit makes the most sense for users of virtualization, gaming, and other areas that can make use of the extra registers and memory address space.

I meant more like EVE Online and a couple other MMOs (no shooters). Thats about the heaviest app I run though

I switched from slack 13.1 64 to 32.Cant sat I have noticed a difference.

I know next to nothing about Slackware, so I can't give much useful advice on that topic.

I've found 32 bit apps and libraries moderately inconvenient to install on Mepis (but certainly not "huge problems). I've found them much easier to install on Centos.

Unless a system is seriously short of ram, I personally would select a 64 bit OS even if I was intending to run 32 bit apps.

I expect you won't notice a hit in performance. I haven't seen results from many controlled experiments on that performance difference. The testing I've done myself has given mixed results.

I suggest a PAE kernel, so you can use your full 4GB of ram.

wouldn't it be better to use a bigger graphics card (if you use the pc for gaming, designing...) instead of switching from 32b to 64b??

With games, the only ones I have tested are Quake Wars and Savage 2, both are slightly faster on 64-bit, I mean like 10-20 FPS more, nothing that you will notice if you have a good video card. If you encode videos you'll probably notice more of a difference.

Usually the only reason a 64 bit app is faster is because it was compiled on a newer compiler and didn't have to take into account legacy issues. They are not faster as such by any hardware issue. It could be that some amount of ram is being paged in larger apps with huge files but that less common.

I doubt you would notice with your eye any difference. It would be one of those test deals pitting lame 64 against lame 32 and saving 1 second on a 30 second task. Could you see it? Well, maybe yes maybe no.

I don't think the compiler itself is typically newer.

But the machine architecture itself is newer, so there are fewer significant variations between models, vs. 32 bit x86 where a compiler (even a new one) has to deal with the possibility that the code will run on older CPU models.

They are faster by many hardware issues.

The most important speed issue might be use of SSE floating point vs. legacy floating point, which would qualify as a legacy issue (not a hardware issue) because most 32 bit x86 systems support SSE floating point, but the compiler uses legacy floating point for 32 bit anyway.

x86_64 also has twice as many registers. That could allow slightly faster code in many cases with almost any compiler. But GCC is especially flawed in its ability to deal with register shortage (compared to other compilers) so the speed advantage from doubling the number of registers is especially important for code compiled by GCC.

x86_64 also can do 64 bit integer math in single instructions, which take multiple instructions for 32 bit x86. If 64 bit integer math were common, that would be an overwhelming performance difference. But 64 bit integers are used almost exclusively in support of 64 bit pointers, almost never as independent integers. So 32 bit programs almost never use 64 bit integers and thus are not slowed down by requiring multiple instructions for 64 bit integer operations. 32 bit x86 and x86_64 both have full support for 64 bit floating point.

Those and many other differences balance against many performance disadvantages of x86_64. The most important is that pointers are twice as big and many programs use a lot of pointers, so an x86_64 program will have a higher L2 cache miss rate than an equivalent 32 bit program (when both are run on the same 64 bit CPU).

The typical computer operation for an ordinary user might be too fast to notice or might need to wait for the hard disk or more likely the network. The CPU speed is less often the bottleneck. So the net performance difference (x86_64 advantages minus disadvantages) is a small difference affecting the aspect of performance that usually doesn't matter.

I can't even guess what that is supposed to mean.

I agree.

But why are both "lame"?

That really depends on the task. For a typical 30 second task, where the network or disk is the bottleneck the difference would be zero seconds, not one. A CPU bound 30 second task would often have a difference much larger than 1 second out of 30. But that difference could go either way. 64 bit is sometimes slower. The average difference would be very hard to measure (or even to define) and probably would be quite small.

1 members found this post helpful.

I was confused by that at first too, but I think he meant this:

http://lame.sourceforge.net/