[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian ppc64

Sven Luther wrote:

On Mon, Dec 20, 2004 at 01:59:44PM -0800, Joaquin Menchaca wrote:
Benjamin Herrenschmidt wrote:

On Sun, 2004-12-19 at 13:50 +0100, Andreas Jochens wrote:

It is of course true that some other distributions put 32 bit libraries
in /usr/lib and 64 bit libraries in /usr/lib64. I will not follow that path because for a native 64 bit distribution this will lead to an almost empty /usr/lib directory while all the native libraries are in /usr/lib64. In other words this would mean to change the name of the well established '/usr/lib' hierarchy to '/usr/lib64'. This would be ugly, at least IMHO.
I'm still rather unsure of the interest of having the ppc64 distribution
be native... Unlike amd64, as I wrote several times, there is no benefit
as in more registers etc... All you'll get is bigger/slower code...


Oh. There's no ppc64? Aaaah. I assumed it was 64-bit. I am interested in getting ppc64 distribution. Though, then if there's no real performance gain, then I guess this is a moot point.

I vaguely recall long ago in another proccessor architecture, Alpha, there was a handbook about building optimized code for that platform to get significant performance gains, like how for loops are created and 64-bit aligned data, etc. I don't know if any of that would be applicable for the G5 architecture. Still, I can't for the life of me imagine 32bit code running like/similar speeds of 64bit code, and gain no perfomance. Hmpf! :-(

Well, as i recall, the powerpc instruction set was designed with 64bit in
mind, and the original spec had a 64bit extension. It took a long time to go
from the ill fated ppc620 which never happened to the power3 and finally the
G5 and later power4/5 chips, but still it was designed for 64bit back then.

Actually, as i recall, the 64bit code should be slower, since all pointers are
now 64bit, and thus you have to transfer double amount of code from the ram
and so on. The only reason amd64 benefit from the 64bitness is the intrinsic
deficiency of the x86 instruction set, and its lame number of usable registers
(8 of which at least 2 are not usable as i understand), which are doubled for
amd64 to 16 (compared to 32 for both ppc32 and ppc64). I doubt that you had
any 64bit optimization stuff for alpha, since alpha where always 64bit from
the start, and seem to be a dead CPU now that intel and compaq have killed it.


Sven Luther


That clears up a lot. There actually was a lot of optimization needed, but this was because of how lammo compilers generated the dysfunctional assembler. Most still think in 32-bit mindset and ignore generic optimizations.

On the Intel/Compaq, it's a shame. Sigh! Compaq had a good thing going, but deplorable mismanaged their business, forcing Tandem to use Alphas instead of MIPS, while killing the Alphas at the same time for instance. Surprisingly, they're still kicking, don't know how. I even had job inquiries for Digital (Tru64) UNIX Administrator.

I still cross my fingers for a revival of that architecture, now that the whole IA64 bombed. HP might have some sense to dump PA-RISC and the ever buggy HP-UX. (I'll duck out know, in case anyone is in love with those platforms...).

 -- Joaquin

PS - When Compaq purchased Tandem, you know what the joke names for the merged companies were?!? :-) "Tampaq" and "Condem". Though, I don't think the executives took the employees advice. :-)

Reply to: