Re: Please upgrade your machines to sparc64

[David Miller]

From: alexmcwhir...@triadic.us
Date: Thu, 23 Jun 2016 16:12:35 -0400

> 1. Oracle knows sparc32 is faster than sparc64, that's why nearly half
> of Solaris is 32 bit.

+1

Re: Please upgrade your machines to sparc64

[alexmcwhirter]

On 2016-06-23 04:30, John Paul Adrian Glaubitz wrote:

On 06/23/2016 07:54 AM, Alex McWhirter wrote:
I spend most of my time working on pure 64 bit sparc linux. simply 
because that's where all the work is currently being done. That being 
said there are

noticeable speed improvements with some applications being 32 bit.


Where did I say that it is impossible to run 32-bit applications? I
never claimed that!


I never claimed that either. The point was that i work on 64 bit because 
it's what being actively developed / need implemented if linux for sparc 
want to have a future.




As far as I know Debian doesn't really have a way of managing 
something like that.Sure you can compile everything both 64 and 32 bit 
and install whichever you
want, but there's no way to really say one package should always be 32 
bit while another should always be 64 bit. Even if that did exist 
sparc is the only

architecture I'm aware of that would really benefit from it.


Except that Debian has the best mechanism to resolve that which is
called Multi-Arch. You can install libraries
and binaries of *any* architecture onto *any* machine. In fact, I am
doing that to cross-compile things like
GHC, see:


https://wiki.debian.org/DebianPorts/BootstrappingGHC




Again, you're missing the point i was trying to make. A default install 
of Solaris includes a mix of 32 bit / 64 bit binaries depending on what 
the applications needs are. I can't think of any Linux distro that does 
that. Using Debian amd64 as an example, you get a full 64 bit system 
until you add i386 as an arch and install what you need as i386 
binaries.


There is no way that i know of (short of doing it all by hand) to build 
a single repository that has 32 bit applications / libs for some things 
and 64 bit applications for others. Short of building such to tool, the 
only option is to have a full 64 bit or full 32 bit userland and allow 
the end user to use a different ABI per application if they wish.


If you build two repositories (one 32 bit and one 64 bit), there is no 
easy way to prefer 32 bit packages for some things and 64 bit packages 
for others. You can easily prefer entire repositories, but not each 
package within those repositories.


The point isn't whether you can install packages for both ABI's. The 
point is that there is no current way to have a mixed 32 bit / 64 bit 
userland by default that is optimized based on a applications needs. Not 
without doing a ton of work by hand.


My unofficial Gentoo ports support multilib for people wanting the 
best of both worlds. But making it a seemless experience providing the 
best performance based
on each applications needs is something that would take a ton of work. 
It may not even be possible with the current packaging system.


Multilib alone is an outdated and insufficient concept and the reason
why we long had ugly solutions like ia32-libs
in Debian which carried 32-bit versions of important libraries
repackaged as 64-bit packages. These days, this has
become completely redundant since you can just directly install i386
packages on an amd64 system if you need 32-bit
support on x86_64, for example.



Debian's idea of multilib != Gentoo's idea of multilib. This is mostly 
because Gentoo doesn't distribute binaries (except in very rare cases).


Gentoo may have similar issues, but because all package are built from 
source i can just add "ABI=sparc32" to each package that doesn't need 64 
bit support.



However, it doesn't end there. You can even go further and install
i386 packages on a ppc64el machine and run them
seemlessly there through qemu-user. Although we are currently missing
up-to-date 32-bit sparc packages which you
could install on sparc64 via MultiArch (unless you want to use the old
ones), there is nothing that stops you from
setting up a small mini-dinstall server, set up an sbuild schroot for
sparc and build custom packages for sparc
instead of sparc64.



Gentoo offers the same, but again the solutions they offer aren't as 
robust because they don't have to deal with the whole binary package 
aspect. One repo is good for all archs.



Thanks to the Debian rebootstrap project [1], we are constantly making
sure that bootstrapping sparc on Debian will
still be possible if required. The project is still under development,
but it's already possible to just cross-
bootstrap sparc with current packages on any host architecture.

Thus, I don't think any of the objections brought up against the
sparc64 port are valid. Neither is sparc64 64-bit
only nor does anyone anyhow prevent you in Debian to mix packages from
different architectures. In fact, Debian
has by far the most flexible approach to resolve the 32-bit/64-bit
problem by providing a generic approach for
mixing libraries of different architectures.

Adrian


[1] https://jenkins.debian.net/view/rebootstrap/


This wasn't supposed to be a "64 bit vs 32 bit vs debian vs gentoo" 
post... I really don't care what other people 

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 21:42:41 +0200

> On 06/23/2016 09:37 PM, David Miller wrote:
>> We're not asking for the old "pure" 32-bit sparc port.
>> 
>> Just a v8+ one, that doesn't support any pre-sparc64 hardware.
>> 
>> Also a large entity doing something doesn't make it the correct
>> thing to do.
> 
> I'm out of this discussion. This is annoying.
> 
> I'm not going to change my opinion on this. I'm not going to go against
> the main flow. I am not getting paid for this, I am doing this completely
> in my free time, so I don't understand why I constantly have to justify
> myself.
> 
> I have invested lots of time and effort to get Debian's sparc64 port to
> where it is now and I'm not going to let this diminished by the naysayers.

You can do a good job and do useful work for people, which you
seem to have done.

But your decisions are still up for criticism and analysis.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 21:33:34 +0200

> On 06/23/2016 09:31 PM, David Miller wrote:
>> And all of those binaries you say "don't matter" take up memory,
>> swap space, etc.  And if you add this up for the entire system
>> it's non-trivial.
>> 
>> Multiply this by some factor N when virtualization is involved.
> 
> On a machine with 8 TiB of memory? I have also never heard anyone complain
> about memory issues on x86_64. Are you also running i686 for that reasons?

It's physical memory, cache memory, TLB entries.

Not the amount of physical or virtual "address space" the cpu
supports.

> Intel ICC does exactly that. I even provided a reference for that.

I don't understand how such an optimization is even possible, or would
even apply in common cases where the pointer is actually used.

Re: Please upgrade your machines to sparc64

[Dr. Wolfgang Daum]

Adrian,

for what it is worth, I am very grateful for your efforts and fully support 
your path and approach.


Wolf. Daum

-Original Message- 
From: John Paul Adrian Glaubitz

Sent: Thursday, June 23, 2016 2:42 PM
To: David Miller
Cc: baggett.patr...@gmail.com ; debian-sparc@lists.debian.org
Subject: Re: Please upgrade your machines to sparc64

On 06/23/2016 09:37 PM, David Miller wrote:

We're not asking for the old "pure" 32-bit sparc port.

Just a v8+ one, that doesn't support any pre-sparc64 hardware.

Also a large entity doing something doesn't make it the correct
thing to do.


I'm out of this discussion. This is annoying.

I'm not going to change my opinion on this. I'm not going to go against
the main flow. I am not getting paid for this, I am doing this completely
in my free time, so I don't understand why I constantly have to justify
myself.

I have invested lots of time and effort to get Debian's sparc64 port to
where it is now and I'm not going to let this diminished by the naysayers.

Thanks,
Adrian

--
.''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
 `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 21:25:40 +0200

> As I have mentioned before, the work mainly targets modern
> hardware. We are not doing this so that people can install Debian on
> historic hardware.

We're not asking for the old "pure" 32-bit sparc port.

Just a v8+ one, that doesn't support any pre-sparc64 hardware.

Also a large entity doing something doesn't make it the correct
thing to do.

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 20:42:31 +0200

> On 06/23/2016 05:06 PM, David Miller wrote:
>> I think what irks people the most about what happened, is that the
>> choosen a path is not the most optimal situation for the target
>> platform.
> 
> Why should it be any different for sparc64 than for ppc64el, amd64,
> arm64, mips64el and so on? Is SPARC so extremely inefficient with
> 64-bit pointers? I don't think so.

It makes a significant performance and memory footprint difference.

This is irrefutable.

And all of those binaries you say "don't matter" take up memory,
swap space, etc.  And if you add this up for the entire system
it's non-trivial.

Multiply this by some factor N when virtualization is involved.

> I don't think it makes sense to compile things like dateutils with
> 32-bit pointers for performance reasons. Also, I would assume that
> modern compilers are able to optimize the code well enough that the
> difference between 32-bit and 64-bit pointers isn't too big that
> it justifies the effort.

No compiler is going to optimize away the pointers in the data
structures, and thus get all of those cache line and tlb misses back.

I do all of my work with 32-bit gcc binaries, even thought I often am
using tools I've built myself.

It makes a huge difference.

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/23/2016 09:37 PM, David Miller wrote:
> We're not asking for the old "pure" 32-bit sparc port.
> 
> Just a v8+ one, that doesn't support any pre-sparc64 hardware.
> 
> Also a large entity doing something doesn't make it the correct
> thing to do.

I'm out of this discussion. This is annoying.

I'm not going to change my opinion on this. I'm not going to go against
the main flow. I am not getting paid for this, I am doing this completely
in my free time, so I don't understand why I constantly have to justify
myself.

I have invested lots of time and effort to get Debian's sparc64 port to
where it is now and I'm not going to let this diminished by the naysayers.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/23/2016 09:31 PM, David Miller wrote:
> And all of those binaries you say "don't matter" take up memory,
> swap space, etc.  And if you add this up for the entire system
> it's non-trivial.
> 
> Multiply this by some factor N when virtualization is involved.

On a machine with 8 TiB of memory? I have also never heard anyone complain
about memory issues on x86_64. Are you also running i686 for that reasons?

>> I don't think it makes sense to compile things like dateutils with
>> 32-bit pointers for performance reasons. Also, I would assume that
>> modern compilers are able to optimize the code well enough that the
>> difference between 32-bit and 64-bit pointers isn't too big that
>> it justifies the effort.
> 
> No compiler is going to optimize away the pointers in the data
> structures, and thus get all of those cache line and tlb misses back.

Intel ICC does exactly that. I even provided a reference for that.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/23/2016 09:06 PM, Patrick Baggett wrote:
> Just to adopt a devil's advocate approach here: I could also say that it 
> doesn't make sense to compile dateutils for 64-bit since extended address 
> space is no
> use. I think the point is that there are advantages both ways: having a 
> single set of 64-bit packages is a lot easier to maintain, but David Miller 
> is correct
> in saying that a large majority of packages do not benefit from using 64-bit 
> memory model, but all of them pay a "tax", relative to the 32-bit packages in 
> code
> size, cache usage, etc. Obviously, for stuff like `ls`, I could care less if 
> took 250usec longer due to "64-bitness", but if somehow that caused my builds 
> to
> take 5 extra minutes, I might get annoyed.

I am doing the work in Debian and I am going to do it the way Oracle is doing 
it in their reference distribution. Not following the path that a huge company 
is
already paving with lots of paid developers would just be inefficient and 
Debian's release policy requires that a release architecture has decent upstream
support, both in regard of hard- and software.

As I have mentioned before, the work mainly targets modern hardware. We are not 
doing this so that people can install Debian on historic hardware.

> It's interesting to see, because from a maintainer standpoint, what you are 
> arguing makes a lot of sense, and from David's kernel developer standpoint, he
> probably dislikes what he perceives as inefficient usage of the hardware that 
> slows down his workflow.

It's not slowing down anyone's workflow. You are hugely overestimating the gain 
that using 32-bit pointers is bringing.

> I'm also pretty sure that all of the incredible work you two have been doing 
> to iron out SIGBUS, fix drivers, and many other unspeakable violations of C
> standards will translate to better code if there ever is more demand for 
> 32-bit SPARC packages. Like you said, it shouldn't be a problem to build / 
> upload
> (32-bit) sparc packages, and then install them if desired, right?

Debian has dropped "sparc" and it's not going to come back in the foreseeable 
future since upstream is focusing on 64-bit now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Please upgrade your machines to sparc64

[Patrick Baggett]

On Thu, Jun 23, 2016 at 1:42 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 06/23/2016 05:06 PM, David Miller wrote:
> > I think what irks people the most about what happened, is that the
> > choosen a path is not the most optimal situation for the target
> > platform.
>
> Why should it be any different for sparc64 than for ppc64el, amd64,
> arm64, mips64el and so on? Is SPARC so extremely inefficient with
> 64-bit pointers? I don't think so.
>
> > The most desirable would have been to build the bulk of userland
> > binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx
> > for some v9 cpu), and then for the specific packages that need it,
> > build 64-bit.
>
> I don't think it makes sense to compile things like dateutils with
> 32-bit pointers for performance reasons. Also, I would assume that
> modern compilers are able to optimize the code well enough that the
> difference between 32-bit and 64-bit pointers isn't too big that
> it justifies the effort. Some compilers like Intel's C/C++ compiler
> are actually already automatically generating 32-bit code when possible,
> the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar
> feature in the future.
>
>
Just to adopt a devil's advocate approach here: I could also say that it
doesn't make sense to compile dateutils for 64-bit since extended address
space is no use. I think the point is that there are advantages both ways:
having a single set of 64-bit packages is a lot easier to maintain, but
David Miller is correct in saying that a large majority of packages do not
benefit from using 64-bit memory model, but all of them pay a "tax",
relative to the 32-bit packages in code size, cache usage, etc. Obviously,
for stuff like `ls`, I could care less if took 250usec longer due to
"64-bitness", but if somehow that caused my builds to take 5 extra minutes,
I might get annoyed.

It's interesting to see, because from a maintainer standpoint, what you are
arguing makes a lot of sense, and from David's kernel developer standpoint,
he probably dislikes what he perceives as inefficient usage of the hardware
that slows down his workflow.

I'm also pretty sure that all of the incredible work you two have been
doing to iron out SIGBUS, fix drivers, and many other unspeakable
violations of C standards will translate to better code if there ever is
more demand for 32-bit SPARC packages. Like you said, it shouldn't be a
problem to build / upload (32-bit) sparc packages, and then install them if
desired, right?

Honestly, I'm just happy to have a working kernel/userland/installer!
That's a great base to launch any further operations, so thanks to both of
you.

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/23/2016 05:06 PM, David Miller wrote:
> I think what irks people the most about what happened, is that the
> choosen a path is not the most optimal situation for the target
> platform.

Why should it be any different for sparc64 than for ppc64el, amd64,
arm64, mips64el and so on? Is SPARC so extremely inefficient with
64-bit pointers? I don't think so.

> The most desirable would have been to build the bulk of userland
> binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx
> for some v9 cpu), and then for the specific packages that need it,
> build 64-bit.

I don't think it makes sense to compile things like dateutils with
32-bit pointers for performance reasons. Also, I would assume that
modern compilers are able to optimize the code well enough that the
difference between 32-bit and 64-bit pointers isn't too big that
it justifies the effort. Some compilers like Intel's C/C++ compiler
are actually already automatically generating 32-bit code when possible,
the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar
feature in the future.

> And I would assume that would be perhaps binutils and perhaps gcc
> and GIT.
> 
> Yes, the 64-bit packages for everything should exist in the repository
> and be built, but the default install should not have everything
> 64-bit.

I disagree. I think it makes way more sense to use such speed optimizations
for code where it's really needed. That's also the most commonly used approach.

For example, packages like ATLAS hugely profit from per-machine optimization
which is why upstream doesn't recommend using pre-compiled binaries but
build the packages from source. However, no one is going to see huge
differences when building coreutils, dateutils and so on with 32-bit
pointers. You won't see a notable difference when calling "date" unless
you are going to run this command 10.000 per second - but then you are
doing something wrong anyway.

This discussion very much reminds me to the misbelief that some Gentoo
users have that building every package from source with -mnative will
have a huge impact on performance. gcc is already generating code which
is fast enough on all targets for a given -m value that there is virtually
no gain over pre-compiled packages - except for packages like the
aforementioned ATLAS.

Adrian

> [1] https://software.intel.com/en-us/node/523141

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Please upgrade your machines to sparc64

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Thu, 23 Jun 2016 10:30:14 +0200

> Thus, I don't think any of the objections brought up against the
> sparc64 port are valid. Neither is sparc64 64-bit only nor does
> anyone anyhow prevent you in Debian to mix packages from different
> architectures. In fact, Debian has by far the most flexible approach
> to resolve the 32-bit/64-bit problem by providing a generic approach
> for mixing libraries of different architectures.

I think what irks people the most about what happened, is that the
choosen a path is not the most optimal situation for the target
platform.

The most desirable would have been to build the bulk of userland
binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx
for some v9 cpu), and then for the specific packages that need it,
build 64-bit.

And I would assume that would be perhaps binutils and perhaps gcc
and GIT.

Yes, the 64-bit packages for everything should exist in the repository
and be built, but the default install should not have everything
64-bit.

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/23/2016 07:54 AM, Alex McWhirter wrote:
> I spend most of my time working on pure 64 bit sparc linux. simply because 
> that's where all the work is currently being done. That being said there are
> noticeable speed improvements with some applications being 32 bit.

Where did I say that it is impossible to run 32-bit applications? I never 
claimed that!

> As far as I know Debian doesn't really have a way of managing something like 
> that.Sure you can compile everything both 64 and 32 bit and install whichever 
> you
> want, but there's no way to really say one package should always be 32 bit 
> while another should always be 64 bit. Even if that did exist sparc is the 
> only
> architecture I'm aware of that would really benefit from it.

Except that Debian has the best mechanism to resolve that which is called 
Multi-Arch. You can install libraries
and binaries of *any* architecture onto *any* machine. In fact, I am doing that 
to cross-compile things like
GHC, see:

> https://wiki.debian.org/DebianPorts/BootstrappingGHC

> Gentoo also suffers from the same issue although its not as bad onsidering 
> you can switch ABI's on the fly.

Debian isn't suffering from that. Your information is simply wrong.

> My unofficial Gentoo ports support multilib for people wanting the best of 
> both worlds. But making it a seemless experience providing the best 
> performance based
> on each applications needs is something that would take a ton of work. It may 
> not even be possible with the current packaging system.

Multilib alone is an outdated and insufficient concept and the reason why we 
long had ugly solutions like ia32-libs
in Debian which carried 32-bit versions of important libraries repackaged as 
64-bit packages. These days, this has
become completely redundant since you can just directly install i386 packages 
on an amd64 system if you need 32-bit
support on x86_64, for example.

However, it doesn't end there. You can even go further and install i386 
packages on a ppc64el machine and run them
seemlessly there through qemu-user. Although we are currently missing 
up-to-date 32-bit sparc packages which you
could install on sparc64 via MultiArch (unless you want to use the old ones), 
there is nothing that stops you from
setting up a small mini-dinstall server, set up an sbuild schroot for sparc and 
build custom packages for sparc
instead of sparc64.

Thanks to the Debian rebootstrap project [1], we are constantly making sure 
that bootstrapping sparc on Debian will
still be possible if required. The project is still under development, but it's 
already possible to just cross-
bootstrap sparc with current packages on any host architecture.

Thus, I don't think any of the objections brought up against the sparc64 port 
are valid. Neither is sparc64 64-bit
only nor does anyone anyhow prevent you in Debian to mix packages from 
different architectures. In fact, Debian
has by far the most flexible approach to resolve the 32-bit/64-bit problem by 
providing a generic approach for
mixing libraries of different architectures.

Adrian

> [1] https://jenkins.debian.net/view/rebootstrap/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913