| View previous topic :: View next topic |
| Author |
Message |
highland
n00b
Joined: 05 Nov 2008
Posts: 71
|
 Posted: Fri Nov 07, 2008 6:38 pm Post subject: gentoo adm64 slower than x86 ?!? |
 |
|
hello
I've decided to make detailed tests. I have laptop dell lattitude D620, Core Duo T5600, 1GB DDR2, sata 120GB.
I've compiled two systems: x86 and amd64.
Recompiled everyhing. For both used:
CFLAGS="-O2 -pipe -march=nocona"
I've run sevral tools like: bonnie++, httperf, bw_mem, lmdd, nbench, bashmark
Every test was similar (from KDE, same demons launched etc..)
I was very surprised but x86 seems to be faster than amd64.
x86 won about 25 from 30 tests.
How is it possible ? Did you run similar tests ?
Thanx |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 10052
Location: almost Mile High in the USA
|
| Posted: Fri Nov 07, 2008 7:16 pm Post subject: |
|
|
64 bits does not equate with faster.
Software needs to be rewritten to take advantage of the architecture. If it's not optimized or has no need for the additional 32 bits, it will not obtain any benefit from 64-bit.
That being said, for the most part, 32- and 64- bit code should run similarly, if you see a 10x difference between the two on nonoptimized software, you probably have a configuration issue.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
highland
n00b
Joined: 05 Nov 2008
Posts: 71
|
| Posted: Fri Nov 07, 2008 7:32 pm Post subject: |
|
|
i hoped that gcc durring compilation would try to optimize for additional 32bit, but did not (or tried but without success)
adm64 seems to be about 5% slower than x86.
Is there any rational reason we should use adm64 ?
Thanx |
|
| Back to top |
|
|
loftwyr
l33t
Joined: 29 Dec 2004
Posts: 970
Location: 43°38'23.62"N 79°27'8.60"W
|
| Posted: Fri Nov 07, 2008 7:37 pm Post subject: |
|
|
Nope, 64bits isn't right for everyone. If your whole basis for choice is the speed of something, you should stick with 32bits. If you need the extra capabilities of 64bits, then upgrade.
_________________
My emerge --info
Have you run revdep-rebuild lately? It's in gentoolkit and it's worth a shot if things don't work well.
Celebrating 5 years of Gentoo-ing. |
|
| Back to top |
|
|
zyko
l33t
Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany
|
| Posted: Fri Nov 07, 2008 7:48 pm Post subject: |
|
|
x86 binaries are smaller. Smaller code is usually faster. Even if code enlargement claims to be due to "optimization", the unoptimized but smaller alternative is still likely to be faster.
| Quote: | | Is there any rational reason we should use adm64 ? |
Amd64 allows for many great improvements in software that does heavy duty computation. Most users just simply don't have any such software. |
|
| Back to top |
|
|
scyld
n00b
Joined: 31 Jan 2006
Posts: 59
|
| Posted: Sat Nov 08, 2008 5:14 am Post subject: |
|
|
| highland wrote: | | Is there any rational reason we should use adm64 ? |
There are couple of reasons. First, the amount of RAM you have or plan to use – if it's 4GB or more – use amd64 as it can, at least, address 2^40 of physical memory and 2^48 of virtual memory. If you have apps for digital video processing or processing large amount of data – especially databases, games with 3D engines or scientific computing which all are ported to 64bit mode then you can benefit from 64bit which can be even twice faster in such cases. |
|
| Back to top |
|
|
highland
n00b
Joined: 05 Nov 2008
Posts: 71
|
| Posted: Sun Nov 09, 2008 2:37 pm Post subject: |
|
|
The only reason for me is amount of memory, BUT:
- i will not have any process which takes more than 2GB of memory
- i will have several (up to 4) such processes that could take almost 2GB of memory
That's why i plan to buy 8GB of memory. But as i understeand - 32bit system will be able to hadnle
such amount of memory because of PAE support.
So i do not need adm64, and most peope (which do not need more than 2 or 3GB memory for user space of process) do not need adm64. |
|
| Back to top |
|
|
loftwyr
l33t
Joined: 29 Dec 2004
Posts: 970
Location: 43°38'23.62"N 79°27'8.60"W
|
| Posted: Sun Nov 09, 2008 3:19 pm Post subject: |
|
|
32bit can handle it but at the cost of a major slowdown as it has to page the memory instead of directly accessing it.
_________________
My emerge --info
Have you run revdep-rebuild lately? It's in gentoolkit and it's worth a shot if things don't work well.
Celebrating 5 years of Gentoo-ing. |
|
| Back to top |
|
|
highland
n00b
Joined: 05 Nov 2008
Posts: 71
|
| Posted: Sun Nov 09, 2008 7:51 pm Post subject: |
|
|
| Is it really great slowdown ? Paging is working anyway. Has anybody measured it ? |
|
| Back to top |
|
|
x22
Apprentice
Joined: 24 Apr 2006
Posts: 208
|
| Posted: Mon Nov 10, 2008 8:55 am Post subject: |
|
|
32bit kernel cannot access highmem directly. Highmem is used for all memory above 1GB (not only in PAE mode).
Userspace in PAE mode just needs another level of page tables and larger page table entries, nothing more. (Unless one process wants to address more than 3GB (virtual) memory.) |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Mon Nov 10, 2008 10:15 am Post subject: |
|
|
| x22 wrote: | 32bit kernel cannot access highmem directly. Highmem is used for all memory above 1GB (not only in PAE mode).
Userspace in PAE mode just needs another level of page tables and larger page table entries, nothing more. (Unless one process wants to address more than 3GB (virtual) memory.) |
I don't know if it's a good example but have a look at fastmail's blog (this is not specific to apps but caching):
http://blog.fastmail.fm/2007/09/21/reiserfs-bugs-32-bit-vs-64-bit-kernels-cache-vs-inode-memory/
| Quote: | | Here you can see how before the 64-bit kernel, it wasn’t possible to have more than 100,000-200,000 inodes in the inode cache at a time. After the 64-bit kernel, the inode cache can easily grow up to almost 2 million items with no problems. |
in general this system isn't slower than ~x86 (maybe a little) but since the kernel and everything around it got faster there's hardly any difference in everyday usage (using office, printing, etc.)
you'll however see that a lot of apps (xsane, gimp, lame, etc.) will be much faster)
to name some examples for processes who need more than 3 GB (not only virtual but real memory):
* ld-linux.so.2 (acrobat reader  )
* X-server (there's a memory hole somehow so if there's not enough memory it crashes)
* ...
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004  |
|
| Back to top |
|
|
ConnClark
n00b
Joined: 15 Aug 2007
Posts: 57
|
| Posted: Tue Nov 18, 2008 11:12 pm Post subject: |
|
|
I have had nothing but things running faster on amd64. Back when I was doing embedded linux development firmware builds took 20% less time under AMD64 than under x86.
AMD64 should be faster in most real applications for two reasons. In 64 bit mode the processor has twice the number of registers to work with. Also in 64 bit mode the ABI uses register parameter passing by default.
Edit: I do not have a multilib install. I have a pure 64 bit system. Also if your processor supports it, using the -msahf flag reduces bloat a little
_________________
In formal computer science advances are made by standing on the shoulders of giants. Linux has shown that, if there are enough of you, you can advance just as far by stepping on each others toes. |
|
| Back to top |
|
|
fabien29200
n00b
Joined: 12 Jun 2006
Posts: 32
|
| Posted: Wed Nov 19, 2008 2:29 pm Post subject: |
|
|
I am also surprised.
I had a Core2 Duo with and installation and I changed for x86_64.
And I real felt better performances in everyday use.
Compilations, launches of heavy programs (gimp, open office) are faster (it's just a feeling with no benchmarks, but I don't think this is an illusion). |
|
| Back to top |
|
|
Attila
Tux's lil' helper
Joined: 28 Feb 2003
Posts: 93
|
| Posted: Fri Nov 21, 2008 12:03 pm Post subject: |
|
|
Hiho,
Right. 64 bit are not neccessary faster. Normaly 64 bit optimized code isn't slower than 32 bit optimized code, but sometimes ...
My reason to switch to 64 bit is h264 encoding. It is alsmot 40% faster under 64bit as under 32bit (same system). So 40% just for switching from 32 bit to 64 bit? - Very nice improvemnt for no cost.
Atti |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Fri Nov 21, 2008 12:16 pm Post subject: |
|
|
| highland wrote: | i hoped that gcc durring compilation would try to optimize for additional 32bit, but did not (or tried but without success)
adm64 seems to be about 5% slower than x86.
Is there any rational reason we should use adm64 ?
Thanx |
Your cflags will ensure that the compiler produces specific code for x86_64, but nothing else. That will not ensure that that the algorithms will be the best suited for x86_64. Those are very different things. The real problem with x86_64 is that only a few programs have been really refactored to do something useful with it. For the rest of programs all you get is an extra usage of ram, when it comes to pointers and word-like types depending on your programming language and the compiler. It shouldn't really be a big deal. In my experience something like a 10%-15% increase in size, though I certainly only checked the htop output and not the binary file size in disk. I am not that worried about it.
The x86_64 architecture is superior, but we are still running x86 programs on it on most cases, that's why it hasn't yet shown its potential on most areas. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2664
Location: Heidelberg - Germany
|
| Posted: Wed Dec 10, 2008 2:42 pm Post subject: |
|
|
| Attila wrote: | Hiho,
Right. 64 bit are not neccessary faster. Normaly 64 bit optimized code isn't slower than 32 bit optimized code, but sometimes ...
My reason to switch to 64 bit is h264 encoding. It is alsmot 40% faster under 64bit as under 32bit (same system). So 40% just for switching from 32 bit to 64 bit? - Very nice improvemnt for no cost.
Atti |
which application are you using for encoding H264?
-Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H 64GB RAM mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
devsk
Advocate
Joined: 24 Oct 2003
Posts: 3003
Location: Bay Area, CA
|
| Posted: Wed Dec 10, 2008 5:08 pm Post subject: |
|
|
| Erdie wrote: | | Attila wrote: | Hiho,
Right. 64 bit are not neccessary faster. Normaly 64 bit optimized code isn't slower than 32 bit optimized code, but sometimes ...
My reason to switch to 64 bit is h264 encoding. It is alsmot 40% faster under 64bit as under 32bit (same system). So 40% just for switching from 32 bit to 64 bit? - Very nice improvemnt for no cost.
Atti |
which application are you using for encoding H264?
-Erdie |
application will only determine convenience, the speed is driven by x264 package. avidemux is what I use when I don't know what the source content (interlaced vs. progressive, 24fs vs 25fps vs 30fps) is. Otherwise, I use mencoder because updating the GUI screen does take the CPU away from x264.... I use 3 threads in x264 settings on a dual core. Have lately become fond of single pass because I can't tell a difference between 2 pass encoded content and 1 pass encoded. In fact, in some cases, 1 pass did a better job (may be 2 pass is trying too hard to save a few bits) with quality with only a few KBs of extra space. |
|
| Back to top |
|
|
|
Gentoo on AMD64
