Am Montag, 13. August 2012, 20:55:23 schrieb Frank Steinmetzger:
> Hey there
> 
> As I mentioned in an earlier thread, I switched from 32 to 64 bit after some
> convinction work done by the ML and a friend.  In order to justify the
> switch for myself, I made some performance comparisons.
> 
> So, in case anyone is interested, here are my results.
> 
> The only thing I don't really like is of course the increased RAM usage.
> While the old installation took 400 MB of RAM after Login to KDE (Akonadi is
> a hog), it now takes 500.  The memory meter now stands always at least at
> 50% (3 GB available).  I will have to tune down multitasking a bit.
> 
> 
> 
> The following items first display the command excuted (denoted by $), and
> then the output of time for the command; first for 32 bit and then 64 bit.
> 
> All tests were done on my Core 2 Duo laptop (T7200, max. 2GHz) fixed at 1
> GHz and with 3 GB of RAM.  This is not a theoretical benchmark, but rather
> about stuff I usually to do in my every-day computing.  I excluded
> compiling, because it involves more than just crunching.
> 
> Resulting observation: there seems to be an inherent increase of about 10%
> in memory throughput.  I was most surprised by the performance of lilypond
> and blender, two computing-intensive applications I tend to use regularly.
> I wanted to do a framerate comparison of the Java-based CPU hog Minecraft,
> but didn't get around to it.
> 
> 
> All the following tasks were done in ramdisk to rule out HDD hindrance.
> 
> 
> 
> $ 7z b (7zip's own benchmark function, abridged output)
> 
> 32 bit                              |   64 bit
> ===========================================================================
> RAM size:    3037 MB                |   RAM size:    3013 MB
> RAM usage:    425 MB                |   RAM usage:    425 MB
> 
> Dict  Compressing  | Decomp.        |   Dict  Compressing   | Decomp.
>       Speed Rating | Speed Rating   |         Speed Rating  | Speed Rating
>        KB/s   MIPS |  KB/s   MIPS   |          KB/s   MIPS  |  KB/s   MIPS
> 
> 22:    1487   1446 | 19039   1719   |   22:    1612   1568  | 20974   1893
> 23:    1443   1470 | 19049   1744   |   23:    1612   1642  | 20758   1900
> 24:    1499   1612 | 18854   1749   |   24:    1591   1711  | 20292   1883
> 25:    1489   1700 | 18611   1750   |   25:    1584   1809  | 20030   1884
> --------------------------------------------------------------------------
> Avr:          1557           1740   |                 1682            1890
> Tot:          1649                  |                 1786
> 
> 
> 
> Various compressions of the High Voltage SID collection version 56
> (41356 files, 1416 folders, total dir size 307.676k according to du -s).
> 
> Extract:
> $ unrar x hvsc.rar
> real    0m38.582s   0m38.763s
> user    0m36.031s   0m36.190s
> sys     0m2.523s    0m2.496s
> ---> neglibible
> 
> Repack witz p7zip, resulting archive size 54.8 MB:
> $ 7za a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on hvsc.7z C64Music/ >
> /dev/null real    3m0.530s    2m41.780s
> user    5m22.359s   4m55.810s
> sys     2m2.973s    0m3.144s
> ---> 1/9 faster
> 
> Extract from 7z:
> $ 7z x hvsc.7z
> real    0m24.541s   0m21.437s
> user    0m19.302s   0m16.929s
> sys     0m4.403s    0m4.472s
> ---> 1/10 faster
> 
> Simple taring of the directory:
> $ tar cf hvsc.tar C64Music/
> real    0m1.334s    0m1.226s
> user    0m0.297s    0m0.304s
> sys     0m1.020s    0m0.872s
> ---> ~1/10 faster
> 
> XZing the tar, resulting archive size 54.2 MB:
> $ xz -k -z hvsc.tar
> real    6m26.383s   4m31.747s
> user    6m23.375s   4m30.969s
> sys     0m2.733s    0m0.728s
> ---> ~1/3 faster
> 
> XZing with --extreme option (about 4% smaller archive):
> $ xz -e -k -z hvsc.tar
> real    15m37.732s  10m39.348s
> user    15m36.592s  10m38.900s
> sys     0m0.977s    0m0.456s
> ---> ~1/3 faster
> 
> Packing in squashfs:
> $ mksquashfs C64Music/ hvsc.sqfs
> real    0m57.380s   0m44.697s
> user    1m45.136s   1m20.377s
> sys     0m9.059s    0m6.116s
> ---> ~1/4 faster
> 
> 
> 
> Some memory shuffling:
> $ dd if=/dev/urandom of=random bs=1M count=500
> real    2m0.306s   1m49.348s
> user    0m0.003s   0m0.000s
> sys     2m0.292s   1m49.315s
> ---> 1/12 faster
> 
> $ cp random r2
> real    0m1.069s   0m0.917s
> user    0m0.000s   0m0.004s
> sys     0m1.067s   0m0.908s
> ---> 1/10 faster
> 
> 
> 
> Compile Bach's Christmas Oratorio, Tenor part, 16 pages A5:
> $ lilypond wo.ly
> real    0m31.430s  0m23.737s
> user    0m30.711s  0m23.129s
> sys     0m0.717s   0m0.592s
> ---> 1/3 faster
> 
> Compile Oratorio de Noël by Saint-Saëns, 4 voices, 16 pages A4:
> $ lilypond noel.lyk
> real    0m41.575s  0m26.494s
> user    0m41.177s  0m25.870s
> sys     0m0.390s   0m0.604s
> ---> >1/3 faster
> 
> 
> 
> Optimising a PNG (photo of Orion nebula, 1400x1050 pixel):
> $ optipng -o9 Orion.png
> real    0m23.491s  0m21.337s
> user    0m23.465s  0m21.281s
> sys     0m0.027s   0m0.008s
> ---> 1/10 faster
> 
> 
> Encoding a video file to x264 (1280x960, 1600 frames, no sound):
> First pass:
> $ mencoder bike.flv -ovc x264 -x264encopts bitrate=2000:pass=1 -nosound -o
> /dev/null real    1m57.379s  1m44.500s
> user    3m48.048s  3m19.728s
> sys     0m0.837s   0m0.796s
> ---> 1/8 faster
> 
> Second pass:
> $ mencoder bike.flv -ovc x264 -x264encopts bitrate=2000:pass=2 -nosound -o
> bike.avi real    4m53.233s  4m15.533s
> user    9m41.169s  8m26.660s
> sys     0m0.990s   0m1.144s
> ---> 1/8 faster
> 
> 
> Rendering a small test scene in Blender 2.63
> (http://www.eofw.org/bench/test.blend): (file's scene defaults: 800x600,
> one thread)
> win32      2:59
> Gentoo32   2:57
> Gentoo64   2:09
> ---> > 1/3 faster

so all in all you got performance improvements you had to spend several 
hundred of dollars for just through recompiling. Should give you food for 
thought.

Oh and the ram? Ram is cheap. Get yourseld 8gb. Costs as much as a good lunch. 
Or a couple of beers on friday night. 
-- 
#163933

Reply via email to