![]() | ||||||||||
Messages in this thread |
"David S. Miller" <davem@redhat.com> writes: > X86_64 on the other hand seems to run x86 binaries in a similar > fashion. I don't know how people currently doing this port intend Yes it does. > to do the useland, but I bet it would benefit from a mostly 32-bit > userland just like sparc64/ppc64 does, both in space and performance. Apart from a few unfortunate exceptions[1] the code size growth from ia32 to x86-64 is very moderate. The binaries appear a bit bigger because they have an .ehframe linked in by default, but .text growth is not that bad (normally 5-10%, in some cases it even gets smaller) Random sample (with .ehframe stripped): 64bit ls: -rwxr-xr-x 1 root root 76672 Oct 25 05:59 /bin/ls text data bss dec hex filename 64847 7752 1136 73735 12007 /bin/ls 32bit ls: -rwxr-xr-x 1 root root 68524 2002-09-09 22:56 /bin/ls text data bss dec hex filename 65353 1112 872 67337 10709 /bin/ls [< 1K .text growth, some .data growth due to 64bit pointers] Performance is good too and gcc is a lot happier with 16 general purpose integer registers than with 8. The current x86-64 distributions I'm aware of have a full 64bit userland. That said you can run a 32bit distribution with a 64bit kernel just fine, with the exception of modutils, but that should be fixed now with the 2.5 in kernel module loader. Good 32bit emulation is a goal for the port. So you can run what you want - 32bit or 64bit - but the default is 64bit. -Andi [1] emacs is twice as big because its fundamental lisp word grows from 32bit to 64bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:31 [from the cache] ©2003-2008 | ||||||||||