Re: ppc64 port
Greets,
Peter Bergner wrote:
On Wed, 2004-04-28 at 08:13, Tom Gall wrote:
Benjamin Herrenschmidt wrote:
Well, the later is not true. 32 bits code tend to run faster than 64
bits code on ppc64. Unlike amd64 where you win by having access to more
registers, on ppc64, you just end up having to use more instructions to
load a full constant in a register ;)
Well let's be careful here. As there old saying goes, there's lies, damn
lies and benchmarks.
Yes some operations on PPC64 are slower than they are on PPC32 but that
is not universally true. Given that things are a bit early in the life
of PPC64 current performance is not necessarily a prediction of future
performance. It's not like everyone is working on ppc32 performance and
forgetting ppc64 entirely.
Ben is talking about 32-bit app performance versus 64-bit app
performance on 64-bit hardware, not app performance differences
between 32-bit hardware versus 64-bit hardware.
Getting back to what Ben said, yes, PPC64 apps do tend to need more
instructions for some things. I will say that the compiler is smart
enough to use fewer than 5 instructions for loading constants when
it can. It's cases like code with RELOCS as well as the use of the
TOC where we tend to get more instructions relative to 32-bit apps
and that doesn't help your icache.
Right but I think the assumption being put forward with no real data
behind it is that is that ppc64 apps are always slower than ppc32 apps.
1% slower, 10% slower, these kinds of contexts mean something.
I certainly don't disagree that there are certain code paths for ppc64
that are slower. But on the other hand the sky doesn't seem to be
falling when running a ppc64 box as 64 bit.
I'm aweful curious to do some comparisons.
Let's review where some of the the other distros are at and what they
are doing for x86_64 as well. Everyone (and I mean everyone) has the
ability to run both 32 bit and 64 bit code. The design choice is what is
the "default" mode. IE if a user just calls gcc, are they going to get
a 64 bit app, or a 32 bit app. Install something like apache, will it be
64 bit or 32 bit... etc etc.
1) SuSE SLES 8 for PowerPC64 - Default is 32 bit
2) SuSE SLES 8 for x86_64 - Default is 64 bit
4) Gentoo/ppc64 - Default is 64 bit
5) Gentoo/x86_64 - Default is 64 bit
6) Redhat Enterprise for PowerPC64 - Default is 32 bit
7) Redhat for x86_64 (fedora) - Default 64 bit
8) Redhat exterprise for x86_64 -Default 64 bit
and IIRC Debian x86_64 is 64 bit as well.
Let's resort your list by arch:
x86_64:
2) SuSE SLES 8 for x86_64 - Default is 64 bit
5) Gentoo/x86_64 - Default is 64 bit
7) Redhat for x86_64 (fedora) - Default 64 bit
8) Redhat exterprise for x86_64 -Default 64 bit
and IIRC Debian x86_64 is 64 bit as well.
ppc64:
1) SuSE SLES 8 for PowerPC64 - Default is 32 bit
4) Gentoo/ppc64 - Default is 64 bit
6) Redhat Enterprise for PowerPC64 - Default is 32 bit
Yes, all x86_64 distros are making 64-bit binaries the default.
My point here is two fold.
1) ppc64 and x86_64 share the same characteristic that they both have
good 32 bit performance and compatibility
2) it is better that ppc64 and for that matter all 64 bit architectures
to be consistant,
be it across debian, or the open source universe?
The question is why are they doing that, not "hmmm, if they're
doing that for x64_64, that must be the correct answer for ppc64
too". The reason 64-bit is the default for x86_64 is as Ben
mentioned above, they have access to more registers which leads
to vastly less spill code versus 32-bit apps. Sixty-four bit
apps on x86_64 have the same problem with extra code for some
RELOCS, but that is overwhelmed by the reduction in spill code.
Therefore, the correct solution for x86_64 is 64-bit apps are
the default.
It should not be forgotten that x86_64 is also a better 32 bit processor.
For ppc64, we have 2 out of the 3 distros choosing 32-bit as the
default and only Gentoo/ppc64 choosing 64-bit as the default.
Tom, would you happen to know who decided Gentoo would default
to 64-bit apps? ;-) Sorry, I couldn't resist the little dig!
Wasn't me. It was Brad House. So back at ya! ;-)
Yes I have an interest in a real 64 bit env for ppc64 and thus gentoo/ppc64
was born but that's entirely besides the point. Try building a reasonable
*USEFUL* complete 64 bit environment any other way. It is the odd package
in the linux community that cross builds well. And on a ppc64 box, with
a default
of ppc32, one is sentanced to the cross build penalty box for 64 bit code.
This is an old tired debate. It's happened time and time again, from 8
bit to 16 bit to
32 bit and now 64 bit. Progress marches on, and the number of bits
expands. I shouldn't
wonder if this discussion won't be revisted again and for other orders
of 2. :-)
Certainly there were many motivations pushing from 8 to 16 to 32 and
this time around
the push to 64 bit perhaps isn't as strong. But it's there. Just like
the push to 32 bits back in the early 80s.
There are 2 reasons why we choose 32-bit apps as the default:
1) It was easier during the initial port of the ppc64 kernel! :-)
2) It's the right choice ignoring 1).
When we first started the port of the ppc64 kernel, there was no
glibc port for 64-bit PowerPC Linux and to be honest, even the
gcc and binutils ports were iffy. Anyone remember us using the
gcc that produced AIX assembly and the hacked binutils that groked AIX
assembly and produced ELF files? It wasn't pretty! So what were we
going to run once we got the kernel up and running? Well, the large
number of ppc32 apps already built and ready to go for the 32-bit
distros were just too easy to pass up.
I remember, I was a couple of doors down at the time ;-)
But it's 2004 now. Progress has marched on. Things are alot better.
Now that we have a 64-bit userspace, I think it's still the right choice
given the performance benefit of 32-bit apps over 64-bit apps discussed
above. People complain about having multiple glibc's laying around, but
disk is cheap and if you don't use 64-bit apps that often, it won't even
eat up your memory. However, I'll agree to disagree with anyone who
wants 64-bit apps to be the default.
Well I think it all depends on how far someone wants to go down the
rabbit hole with regards to supporting either 32 bit or 64 bit or both.
Essentially at it's extreme one ends up with two distributions installed
on their box.
But for this audiance and why I care is there is a significant impact to
the developer.
Consider on a machine where you are installing both 32 and 64 bit
packages. How do you
keep things straight in /usr/include? What binaries go where? Make sure
32 and 64 bit packages don't step on each other. etc etc etc. Alot of
issues that us developer types have to deal with.
Tom, even though you selected 64-bit apps as the default for
Gentoo/ppc64, I hope you're not putting 64-bit libs into /lib/ and
/usr/lib/. Ignoring any LSB issues, that would break any chance for
you to use binary packages built on the other distros.
Putting 64 bit libs into /lib and /usr/lib does not break the LSB as far
as I know nor does it preclude running 32 bit apps on a 64 bit box. But
I'd be interested in a pointer to chapter and verse where the LSB says that.
gentoo/ppc64 runs 32 bit ppc apps just fine including those distrubted
as binaries like the IBM JDK for instance.
Regards,
Tom
Reply to: