On Mon, Mar 19, 2007 at 02:51:24AM -0400, Tom Lane wrote: > AFAIK, not building a ppc64 version should not be a "bug", indeed it > likely should be the default. 32-bit code runs faster than 64-bit code > on that arch, and so the only reason to build 64-bit is if you really > need access to more than 4Gb of address space. There are apps that need > that, but not all that many. > > So my position is that libraries should generally be built in both > flavors (since they can't predict which flavor of executable might want > them) but applications should be built as 32-bit unless there's a good > reason why they need a 64-bit address space. On ppc/sparc yes, plus rpm should prefer there 32-bit packages over 64-bit ones (currently it prefers 64-bit), but there should be a way to override this on a per-package basis (things like gdb and a few others that prefer to be 64-bit if possible). > (If you ask me, the interesting question here is why the other arches > don't behave the same way. Any reasonably competent hardware design > should have the property that doubling the bit-volume of traffic to > main memory has a penalty...) On x86_64 the thing that makes 64-bit code more desirable is doubling the number of general purpose registers and a better addressing mode for PIC code (%rip addressing). So for most apps on x86_64 using 64-bit programs is an overall win. On s390x 64-bit code can use direct calls rather than always loading a function address from literal pool and calling indirectly and a few other improvements, so I believe running 64-bit code on s390x is as slow/fast as 31-bit code. Jakub -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
