Can anyone explain why on older laptops, at least Fujitsu-Siemens Amilo A1630, amd64-distros are MUCH slower than x86-distros?

I've tried several distros on it (mostly live sessions, but some installed as well).

Linux Mint 17.1 fxce amd64 was unusable totally, but the x86 version is bearably fast. Worst this far has been 64-bit Zorin. When it had been booting twice the time boot time of the 64-bit Mint, I got tired of waiting, so I don't know about how it might have run. Also Linux Lite 64-bit was slow - about the same as the 64-bit Mint.

I'll post the specs later.

[edit]
It's later now, so:

Oh, and one thing: does anyone know what's the difference between Mint 17 and Mint 17.1 such that in Mint 17 the (notorious) rt2500pci doesn't work (hard blocked) but in 17.1 it works? So if i find a better suited distro, I can still get the wifi to work.

It might be that the 512MB of RAM on that machine is at fault here, possibly the 64 bit versions, that are indeed a bit more memory hungry, hit that limit faster, especially on a live-session, where all changes are stored in RAM. If you look at that inxi info, even on the 32 bit system you already have about 340MB in use, this will be more on a 64 bit system.

1 members found this post helpful.

Could the memory itself affect: one 512 MB module instead of 2x256 MB?

For that big a difference on that hardware, I suspect some failure to control for other differences in the experiment, rather than a true difference between 32-bit and 64-bit.
64-bit is more memory hungry, but 512MB is not that terribly small and the memory difference is not proportional: It is only significant at very low total memory sizes.
64-bit also needs more CPU-cache, so on an older CPU the disadvantage of 64-bit is magnified by having too little CPU-cache. I haven't looked up that level of hardware detail for this configuration, but typically having one 512MB module rather than 2x256MB would further magnify the impact of the CPU-cache being too small.

So I don't find it surprising that 32-bit is faster than 64-bit on that hardware. But the factors driving that difference are all relatively small (compared to the performance differences that might result from other install-time choices) so I'm not convinced a big performance difference is explained by 32-bit vs. 64-bit.

Something weird going on with you not getting rt2500 running.
In any distro. Instead of just 1.

Makes one wonder if you are are getting corrupted iso downloads.

Real Men do md5sum checks.

Edit: I thought you had 1 gig of ram to work with.
Otherwise. I would never have mentioned any XFCE Distro.

MX-14.4 would have been the lightest running XFCE distro when
it comes to 512MB of ram.

I figure a Window Manager would give more joy though than a Desktop
Enviornment.

Yep. I thought something was weird here

Post is from > Posted: Tue Dec 20, 2011

Thread I am referring to

Only slightly, if that CPU even does support dual-channel memory (socket 939 CPUs did, socket 754 CPUs did not). You would see, depending on the application, a difference of about 5% better performance on dual channel systems.

The only explanation for that big difference that comes to my mind is 64-bit CPU on 32-bit bus, but I don't think that such machines have been made...

I asked, because to me it looks unbelievable.
And I run the 'same' live CD/DVD images except 32-bit vs. 64-bit.

I wonder if dual channel was even invented yet, when the machine was made, ;-)

Most definitely was, Early Pentium-4's used dual channel RDRAM vs. AMD using DDR-SDRAM, which was eventually then extended into dual channel DDR-SDRAM to essentially achieve performance parity with RDRAM at a SIGNIFICANTLY reduced price.

I did check with md5sum. I also burned the disk with data check after burning.
The funny thing is that 32-bit Mint 17.1 XFCE was tolerable. Quite close to
64-bit Sparky.
I think rl2500pci stopped working when the rl2500-stuff was replaced with more general rl2x00-stuff. In newer kernels rl2500-stuff seems to be back.
Looks like the the divider is somewhere between kernels 3.13 and 3.14. (although I wonder - Mint 17.1 has 3.13 according to distrowatch). Anyway, the card seems to work with any distro with kernel later than 3.13.

When I run a distro where the card works, lsmod didn't show a single module with 'rl2x00' in the name. Only 'rl2500'.

Remember we are not talking about the direct performance difference between dual channel and single channel, but about the relative impact of that difference for 32-bit vs. 64-bit.

64-bit will execute slightly fewer instructions for the same work accomplished, but those instructions are slightly larger, resulting in fewer accesses to the CPU cache, but (assuming that cache is "too small") more cache misses. The bigger factor is use of pointers within the compiled code. Because 64-bit has more registers it has fewer register "spills", so pointers are read/written between the registers and the cache less often. But those pointers are twice as big, so they take twice as much room in cache and cache miss more often.

It is the higher rate of cache misses (not the direct 64-bit operations, as the OP seems to assume) that results in 64-bit taking a bigger hit from single channel ram than 32-bit takes. The theoretical upper bound on that effect is very high: The cache miss rate could be pushed all the way from 0 to 100% by a change in pointer size (assuming a maximally BAD application behavior to cache size boundary). Then the performance impact is the cost of an entire cache line of dram accesses vs. a single 32-bit access to cache. So far more than 8 to 1, rather than your 1.05 to 1. But that is so spectacularly unlikely, the real world size of the effect should be barely measurable.

Thanks for the clarification, the 5% I mentioned is what I remember from benchmarks at the time when dual-channel was widely introduced.

If, by the assumption here, this:
was meant, well that was kind of joke - I meant data bus multiplexing, like in old 386SX-machines. It loaded 32-bit value from memory to register with a single instruction, but through a 16-bit bus => 2 data fetches for one 32-bit value.

@johnsfine: Did I understand correctly: the cache misses are more heavy since cache lines are twice the size of a 32-bit iron, and that causes twice the bus traffic? Especially when the cache happens to be the same size as in a 32-bit iron, a 64-bit access is almost twice as prone to cache miss as 32-bit?
Or am I totally lost?

That whole concept is obsolete because of caches inside the CPU.

A 64-bit instruction may look like it transfers a 64-bit item of data to or from ram. But it really transfers a 64-bit item to or from cache. The pathway between registers and cache is wider than 64 bits on even the 32-bit CPUs that supported the earliest SSE versions.

The transfer between cache and ram is separate and its width is independent of the width of whatever transfers between registers and cache might have caused the transfer between cache and ram.

I think you are lost.

First, we are not comparing hardware to hardware, but rather use of the same hardware for 32-bit vs. 64-bit software.
Second, the important aspect of the comparison is not the size of transfers, nor the size of cache lines (cache line size doesn't change anyway for 32-bit vs. 64-bit use of the same CPU).

The important difference is quantity of data that must be kept in the cache for efficient operations. In some programs, the bulk of the frequently accessed data consists of pointers. This may seem counter-intuitive to non programmers or to inexperienced programmers. You would expect the "real" data to dominate the total and the pointers to be a small fraction of the total. That is in fact true in some applications. But in many situations that would surprise a non programmer, pointers are the dominant data type used by an application.

64-bit programs typically use the same size characters, the same size integers, and the same size floating point data as 32-bit programs. So if any of those types dominate, the amount of data accessed is basically the same (while the higher register count of 64-bit means that data moves less often between registers and cache and the 64-bit version runs a little faster).

But if the dominant data type is pointers, the size is 64-bit vs. 32-bit. A 64-bit pointer moves between register and cache at exactly the same speed as a 32-bit. A cache line containing a 64-bit pointer moves between cache and ram at exactly the same speed as a cache line containing a 32-bit pointer. The direct impact of the size difference is not what matters.

What matters is that a large number of pointers together take twice as much room inside the cache in 64-bit as 32-bit and crowd each other and other frequently used data out of the cache. So the miss rate is higher.

1 members found this post helpful.

So it's about that a cache line can only contain about half the number of 64-bit entities compared to 32-bit entities? More entities, better chance for hit?

I take that you mean assembly-level when you are talking about pointers (=addresses)?