Re: HPPA and Squeeze
On Thu, 2009-06-25 at 10:10 +0200, Matthias Klose wrote:
> Mike Hommey schrieb:
> > On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
> >> Luk Claes schrieb:
> >>> Matthias Klose wrote:
> >>>> Grant Grundler schrieb:
> >>>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
> >>>>>> Grant Grundler wrote:
> >>>>>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
> >>>>>>> http://lists.debian.org/debian-release/2009/04/msg00303.html
> >>>>>> Note that it's wrong to assume we will come with the answers.
> >>>>> I was expecting a summary of specific issues from an organization
> >>>>> that claims to operate transperently. The hand waving is easy. But
> >>>>> doesn't resolve problems and doesn't meet my expectation of an "open"
> >>>>> organization that I've donated money, time, and materials to.
> >>>> +1. dropping hppa as a release architecture was not communicated by the release
> >>>> team at all. I did spend some time to get gcj / default-jdk working on hppa,
> >>>> and some money (buying a new disk for a hppa machine) to help this port. The
> >>>> time and the money could have spent better, if d-r would have better
> >>>> communicated about their intent.
> >>> There are issues with the hppa port where the release team considered
> >>> dropping it since 2005 communicated to the porter list...
> >>>
> >>>> hppa is not in a good shape, but there are other architectures which are not
> >>>> better (sparc, mips*) from a toolchain point of view. what about these?
> >>> I'm not aware of current toolchain issues on sparc and the issues on
> >>> mips* still seem to be manageable, no?
> >> sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests
> >> to move to v9 optimization by default, which requires some work in the compiler.
> >> I don't plan to update this for upcoming GCC versions, and there's no interest
> >> by upstream to help with this kind of setup. You can't buy v8 software for years
> >> now, but afaik all our machines run 64bit kernels. Maybe it's time to
> >> acknowledge this, remove sparc from the list of release architectures and go on
> >> with sparc64?
> >
> > Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
> > where the pros of the added registers overcome the cons of bigger
> > pointers. In other words, 64 bits code is slower, fatter and more memory
> > hungry than 32 bits code on sparc.
>
> which of the previous statements did you check?
I don't every recall seeing any general purpose comparisons on this; if
anyone has links to one I'd be most interested. I have recollections of
seeing it claimed in some of the Sun manuals and has been accepeted
'cannon' for the entire time I've been using SPARC machines. On
specific programs I've tested I've seen a 10-15% slow down moving from
32 to 64 bit code. The key difference is pointer size and the effect
this has on caching effects; thus the slow down varies program to
program and it is possible that the programs I'm interested in are at
the upper end of the range.
> E.g. speed comparing the current
> 32bit v8 with 64bit ultrasparc code?
I think V9 vs. V8+ would be a fairer comparison, plus there is a
separate question over the default -mtune options to use.
> and even then I wouldn't care that much if it becomes maintainable.
(I guess I don't fully understand the context of this but ...) while
there is GCC support for V8 / V8+ having the userland 32 / kernel 64
split shouldn't be a big deal, should it?
HTH
Cheers,
- Martin
Reply to: