On Wednesday 26 November 2008 02:16:26 John Meacham wrote:
On Tue, Nov 25, 2008 at 09:39:35PM +0100, Ketil Malde wrote:
This corresponds to my experiences - 64 bits is slower, something I've ascribed to the cost of increased pointer size.
ghc unfortunatly also uses 64 bit integers when in 64 bit mode, so the cost paid is increased due to that as well, Also since each math instruction needs an extra byte telling it to work on 64 bit data so the code is less dense.
I've done little exeriment to confirm this. Created simple pgm and ran it with +RTS -s option on couple different harware&OS configurations. main = (putStrLn . show . head . drop 500000) prim divides d n = rem n d == 0 ldf' :: (Integral a) => [a] -> a -> a ldf' (k:ks) n | divides k n = k | k^2 > n = n | otherwise = ldf' ks n prim = filter (\x -> ldf' (2:prim) x == x) [3..] Results of experiment: Win32 Core2Duo 1.8GHz 1GB RAM 17 Mb total memory in use MUT time 56.97s ( 57.02s elapsed) %GC time 0.5% Win32 Core2Duo 2.2GHz 2GB RAM 17 Mb total memory in use MUT time 57.44s ( 57.53s elapsed) %GC time 0.7% (0.8% elapsed) Win32 P4 2.8GHz 1GB RAM 17 Mb total memory in use MUT time 171.64s (175.78s elapsed) %GC time 1.7% (1.5% elapsed) Linux64 Core2Duo 2.2GHz 2GB RAM 41 MB total memory in use (1 MB lost due to fragmentation) MUT time 68.26s ( 68.92s elapsed) %GC time 0.9% (1.1% elapsed) Linux32 Core2Duo 2.3GHz 4GB RAM 17 Mb total memory in use MUT time 51.77s ( 51.83s elapsed) %GC time 0.5% (0.6% elapsed) Experiment confirms your explanations. Also interesting how slow P4 is in comparison to C2D. Best and thanks. Bartek