On Sun, Dec 13, 2009 at 8:16 PM, Paul Jakma <paul(a)dishone.st> wrote:
On Sun, 13 Dec 2009, drago01 wrote:
> such a setup does not make much sense, when your hardware supports x86_64
> not using it for userspace is a waste ....
a) i386 has a lower memory footprint, as has been mentioned in this
Yes which is pretty much the only valid complaint but trading memory
for performance is a price I am willing to take ...
b) The amount of code on your system that is CPU bound and/or
memory-bound due to register pressure, to an extent that the x64
registers would make an appreciable difference is probably not
- kernel hotpots
The kernel doesn't do any have computing...
- graphics hotspots (X server perhaps)
I havn't measured this, but nor have the people who say x86_64 is
faster AFAICT, and there's plenty of experience to say that most
software is far from CPU bound or memory bound.
Yes but the stuff adds up, you gain almost nothing by running i686
code but where it matters x86_64 can make a HUGE difference.
c) There is a definite cost to a distro in having to maintain 2
x86_64 and i386 as separate arches
Not a reason to move forward with hardware development.
d) Like or not, i386 is the de-facto standard for binary interfaces:
- Netscape plugins
This is slowly being fixed.
- Windows executables
Nobody stops you from running i386 apps on a x86_64 system.
- VM images to run in, say, QEMU/KVM
- Sandboxing technologies for, say, browser plugins (I think
Google have stuff in this area)
- Free software windows-only apps (don't know if they exist)
All the code here can be open-source/free-software and still be
relying on i386 as a widely known and hence convenient
/interface/. As such, it likely needs to be supported on x86_64
kernel-based systems anyway, as performantly as possible. (And
yeah, I gather KVM x86_64 doesn't work for i386 VMs - annoying).
Er.. don't quite get your point here, what is stopping me from running
i686 VMs on a x86_64 host?
I have been doing this for a while and there are there problems (you
don't even need multilib for that)
So personally I think x86_64-pure is unrealistic and, independently,
32-on-64 makes sense, but hey. :)
I did not suggest using pure x86_64 but using x86_64 where we can (ie.
not just the kernel).