Please upgrade your machines to sparc64

Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

Hello!

According to to Debian's popularity contest page [1], there are still 82 machines
reporting to be running Debian's old, unsupported sparc port (32-bit userland,
64-bit kernel). Since popcon only reports machines where the users decided to
opt-in, the number of unreported sparc installations will most certainly be
higher.

I would like to ask anyone still running the old sparc port to reinstall their
machines using the sparc64 NETINST installation image [2]. I have just done
that yesterday on a SPARC T200 server and it was very easy when you keep
a few things in mind:

  * when setting up the partitions, create a small (~1 GiB) boot partition
    which is formatted with ext3 and mounted /boot; this is required for SILO
    to work reliably and find the installed kernels
  * when prompted to enter mirror data, use the following:

    - mirror: http://ftp.ports.debian.org
    - directory: /debian-ports/

    although you won't be able to install any packages during installation
    anyway due to the missing Debian Ports signing key (see next point),
    you should still already set up the mirror data here as it will be
    used to configure your /etc/apt/sources.list for the installed system

  * ignore the error message about software packages being unable to be
    installed, just skip this step and you will be fine; you can install
    additional packages easily after rebooting the machine with the installed
    system
  * after skipping the software installation step, just let debian-installer
    finish the installation by installation SILO and completing the remaining
    tasks
  * after the machine has reset and is about to boot the installed system,
    boot the machine with "Linux console=ttyS0,9600,8n1" where "Linux"
    is the name of the configuration in SILO to be booted (defaults to
    "Linux" - view available configurations by pressing <TAB>) and
    console=ttyS0,9600,8n1 configures the serial console which is disabled
    by default currently (I will look into changing this in the future)

After system has rebooted, you should be able to log in using the root login
you created during installation. Before you will be able to install packages,
you need to install the signing key for Debian Ports manually:

# gpg --keyserver pgp.mit.edu --recv-keys 705A2CE1
# gpg --export 705A2CE1 --armor | apt-key add -
# apt-get update

After this, your system should be ready to use and you can upgrade with:

# apt-get update && apt-get upgrade

When dist-upgrading, *always* read what APT is going to do before hitting <ENTER>
and in case some important packages would be deleted, press <n> to cancel. This
issue usually resolves after a certain time when the buildds have caught
up with building new packages.

# apt-get dist-upgrade

>>> Read the warnings about potential packages being removed <<<

Finally, you should install the popularity-contest package to help the popularity
of the sparc64 port:

# apt-get install popularity-contest

The more people are running the sparc64 port of Debian, the easier it will be for
us to convince the release team to make sparc64 an official Debian port!

Thanks,
Adrian

> [1] http://popcon.debian.org/
> [2] https://people.debian.org/~glaubitz/debian-cd/2016-05-04/debian-9.0-sparc64-NETINST-1.iso

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

Re: Please upgrade your machines to sparc64

[Meelis Roos]

> According to to Debian's popularity contest page [1], there are still 82 machines
> reporting to be running Debian's old, unsupported sparc port (32-bit userland,
> 64-bit kernel). Since popcon only reports machines where the users decided to
> opt-in, the number of unreported sparc installations will most certainly be
> higher.

I might have quite a number of machines there :) Most of my sparcs are 
running snapshot of debian sid from Jul 27, 2015, with systemd packages 
slightly earlier (218-something). Getting something newer on them would 
be good...

I have been planning to test the sparc64 port when I get some time, to 
see if it is ready enough to easily upgrade all the machines. From your 
description it seems that it is installable but not ready yet.

>   * when setting up the partitions, create a small (~1 GiB) boot partition
>     which is formatted with ext3 and mounted /boot; this is required for SILO
>     to work reliably and find the installed kernels

I have always wanted to know why? I understanrd there was OBP problem in 
old 32-bit sparc machines that was the reason for this suggestion, but I 
have impression that this is not the case for any sun4u era or later 
OBP.

I have installed most of my sparcs with single root only and never seen 
any problems (OK, my disks usually do not fill up much, most stay under 
10G total - but defintely use more from 1G from the start of the disks 
even for files under /boot).

And silo should support ext4 for years - I have multiple sparcs with 
ext4 root and no /boot and it all still works. Last commit about ext4 in 
silo git was from 2012 so I have the impression that it should work.

Does anyone remember the exact reasons we suggest separate /boot 
partition?

>   * after the machine has reset and is about to boot the installed system,
>     boot the machine with "Linux console=ttyS0,9600,8n1" where "Linux"
>     is the name of the configuration in SILO to be booted (defaults to
>     "Linux" - view available configurations by pressing <TAB>) and
>     console=ttyS0,9600,8n1 configures the serial console which is disabled
>     by default currently (I will look into changing this in the future)

Does <TAB> work in silo for anybody for filename completion?

I reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug'9480 in 
2004 and I am still seeing the same behaviour as far as I can remember.

-- 
Meelis Roos (mroos@linux.ee)

Re: Please upgrade your machines to sparc64

[chase rayfield]

How well maintained is the Debian Sparc port these days and what is
the reason for forcing upgrades to 64bit userland?

Sparcv8+ 32bit code is faster as far as I know in most cases even on
new Sparcs due to memory overhead for 64bit instructions.... telling
people to go pure 64bit is nonsense and certainly isn't what
Gentoo/Sparc does or suggests.

I think sun4u machines had a 2 or 4GB limit on the boot partition
still no idea after that though. I think some/most sun4m could do 2Gb
boot partition and sun4c was 1GB. Not sure about sun4d or e though I
suspect it is similar to sun4m.

Chase

Re: Please upgrade your machines to sparc64

[David Miller]

From: chase rayfield <cusbrar1@gmail.com>
Date: Tue, 21 Jun 2016 19:20:59 -0400

> How well maintained is the Debian Sparc port these days and what is
> the reason for forcing upgrades to 64bit userland?
> 
> Sparcv8+ 32bit code is faster as far as I know in most cases even on
> new Sparcs due to memory overhead for 64bit instructions....

+10000000

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/22/2016 09:13 PM, David Miller wrote:
> From: chase rayfield <cusbrar1@gmail.com>
> Date: Tue, 21 Jun 2016 19:20:59 -0400
> 
>> How well maintained is the Debian Sparc port these days and what is
>> the reason for forcing upgrades to 64bit userland?
>>
>> Sparcv8+ 32bit code is faster as far as I know in most cases even on
>> new Sparcs due to memory overhead for 64bit instructions....
> 
> +10000000

That won't change the fact that the majority of work is now happening on
sparc64. I don't think there is a realistic chance of getting most projects
spending much work on the 32-bit code since the focus is on new hardware.

Either way, Debian sparc (32-bit) is completely unsupported these days
and no longer receiving any security updates. So, anyone should either
use Gentoo or switch over to Debian sparc64.

So far I haven't seen any issues with the sparc64 port, even on my old
Sun Blade 100. Alas, I haven't done any detailed benchmarking yet.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@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 <glaubitz@physik.fu-berlin.de>
Date: Wed, 22 Jun 2016 21:23:40 +0200

> Alas, I haven't done any detailed benchmarking yet.

Too bad, since that's where all the problems will be.

Even just doing a kernel build or a gcc bootstrap, you'll
see it.

And that effects the people like me who you expect to work
on bug fixes.

Frankly, I'm leaving all of my sparc64 machines, yes all of
them, running the unsupported 32-bit userland and will simply
live without upgrades and support.

That's how important this is to me.

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/22/2016 09:46 PM, David Miller wrote:
> Frankly, I'm leaving all of my sparc64 machines, yes all of
> them, running the unsupported 32-bit userland and will simply
> live without upgrades and support.
> 
> That's how important this is to me.

I'm not arguing with you that 32-bit code is faster than comparable 64-bit
code, it absolutely is. Heck, even Intel realized that a few years ago and
they created the x32 ABI [1]. It didn't help though as x32 is rather unpopular
among users and developers. We have a handful of users of the port in Debian
which I also help to maintain, by the way.

And it's not like that people have not run into memory issues when using a 32-bit
process address space. 4 GiB can be easily eaten up when building something
like Firefox with link-time optimization enabled, so I don't think we have
a viable alternative to sparc64 in the long term.

Thanks,
Adrian

> [1] https://en.wikipedia.org/wiki/X32_ABI

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

Re: Please upgrade your machines to sparc64

[Aaro Koskinen]

Hi,

On Wed, Jun 22, 2016 at 09:23:40PM +0200, John Paul Adrian Glaubitz wrote:
> That won't change the fact that the majority of work is now happening on
> sparc64. I don't think there is a realistic chance of getting most projects
> spending much work on the 32-bit code since the focus is on new hardware.
> 
> Either way, Debian sparc (32-bit) is completely unsupported these days
> and no longer receiving any security updates. So, anyone should either
> use Gentoo or switch over to Debian sparc64.

Or compile and maintain your own 32-bit userspace (like I do). For the
stuff I need, upstream projects have no issues with 32-bit.

A.

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/22/2016 10:14 PM, Aaro Koskinen wrote:
> Or compile and maintain your own 32-bit userspace (like I do). For the
> stuff I need, upstream projects have no issues with 32-bit.

That's what I meant when I mentioned Gentoo as an option.

Adrian

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

Re: Please upgrade your machines to sparc64

[chase rayfield]

Actually it's quite different from the x32 ABI.... 32bit Sparc code
has always been fastest by a large margin and has been what everyone
used unlike x32 which is only marginally faster as well as unstable.
On the other hand 64bit on Sparc code has only been used in the small
corner cases were 64bit was indeed faster or large memory access was
needed. I can imagine situations on big iron where a database may be
64bit due to large memory use but any client software also running
would be 32bit...

Also, who seriously runs Firefox on a T4 server or a LEON4 system or
vintage sun4 gear like I have? Though I would applaud someone for
trying it isn't a good point on which to make a decision regarding
userland maintenance. It just isn't a class of software that runs in
any practical sense on Sparc hardware that is in existence. It is far
too bloated for one... Firefox is a worst offender in this area and
depreciated everything else just because it can't build Firefox which
isn't even supported on Sparc anyway... is nonsense. Even on my T2000
it doesn't make a lot of sense to run Firefox even though it is fast
enough Firefox isn't threaded enough for it to use the hardware
efficiently.

sparc64 kernel + 32bit userland will probably never go away it's what
most people should be running. So, you'll just end up loosing userbase
further and inevitably dropping the Debian Sparc port.

Davem, has anything become of getting recent kernels running on sun4m
hardware? I was thinking it might be possible to reduce kernel size
with LTO as yet another temporary workaround until it becomes
relocatable as I think you mentioned would be the real fix.

Chase

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/22/2016 10:54 PM, chase rayfield wrote:
> Also, who seriously runs Firefox on a T4 server or a LEON4 system or
> vintage sun4 gear like I have?

I didn't claim that you should be running Firefox on a T4 server. I was
giving an example of something which needs more than 4 GiB per process
when *linking*, not running it.

Please don't turn this into "Back in the days" flamefest, these discussions
are always stupid. We are doing software engineering and that is subject
to changes because the requirements on the hard- and software are changing
and increasing.

I am coming from a physics background and I used to do number crunching
on machines with 2 TiB of memory (SGI UV-1000). When you are doing
computational physics, 4 GiB are nothing. I have seen single processes
consume 700 GiB which were doing complex matrix calculations.

> sparc64 kernel + 32bit userland will probably never go away it's what
> most people should be running. So, you'll just end up loosing userbase
> further and inevitably dropping the Debian Sparc port.

Sorry, but this is just laughable. Are you seriously saying that someone
is buying a $40k SPARC-T7 server and then start running a self-compiled
32-bit distribution on that? Those machines can be configured with up to 8 TiB
of memory per machine [1]. No one is going to pay so much money and then
not use the capabilities it has.

sparc64 is what Oracle is currently pouring resources into and what
companies who are willing to pay several grand for a new SPARC server
are going to run.

Do you really think that companies are investing into the SPARC port
because they are targeting hobbyists that want to run SPARC Linux
on museum hardware?

Adrian

> [1] http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-t7-m7-server-architecture-2702877.pdf

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@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: chase rayfield <cusbrar1@gmail.com>
Date: Wed, 22 Jun 2016 16:54:51 -0400

> Davem, has anything become of getting recent kernels running on sun4m
> hardware? I was thinking it might be possible to reduce kernel size
> with LTO as yet another temporary workaround until it becomes
> relocatable as I think you mentioned would be the real fix.

I haven't invested any time or effort in this area, so don't know
much about the state of affairs here.

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@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 <glaubitz@physik.fu-berlin.de>
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 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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@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 <glaubitz@physik.fu-berlin.de>
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: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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Please upgrade your machines to sparc64

[chase rayfield]

Just to clarify, unlike variable length ISAs Sparc has fixed 32bit and
64bit ISAs... Sparc v8+ is 32bits for every instruction executed while
for Sparc v9 it is 64bits for every instruction. Thus the overhead is
not just in pointers etc.. as is often the case on variable length
architectures. 64bit instructions potentially waste more cache as well
as use 2x the memory bandwidth. Also note that Sparc does not mix
32bit and 64bit instructions I presume that when a 64bit kernel is
executing 32bit code it switches back out of 64bit mode when returning
to userland...

You may wonder what advantage being so strict about instruction length
is... for one the Ultrasparc instruction decode stages have in the
past at least been wave pipelined... which as you may imagine is made
easier by having regular instruction lengths as well as infrequent
switches between 64bit and 32bit mode.



On Thu, Jun 23, 2016 at 3:31 PM, David Miller <davem@davemloft.net> wrote:
> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> 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

[David Miller]

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
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

[John Paul Adrian Glaubitz]

On 06/23/2016 09:42 PM, chase rayfield wrote:
> Just to clarify, unlike variable length ISAs Sparc has fixed 32bit and
> 64bit ISAs... Sparc v8+ is 32bits for every instruction executed while
> for Sparc v9 it is 64bits for every instruction. Thus the overhead is
> not just in pointers etc.. as is often the case on variable length
> architectures. 64bit instructions potentially waste more cache as well
> as use 2x the memory bandwidth. Also note that Sparc does not mix
> 32bit and 64bit instructions I presume that when a 64bit kernel is
> executing 32bit code it switches back out of 64bit mode when returning
> to userland...

Then please go to Oracle and tell them they are all wrong with what they
are doing. Because it seems you know more about this stuff than the people
who are engineering the actual hardware.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@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: chase rayfield <cusbrar1@gmail.com>
Date: Thu, 23 Jun 2016 15:42:00 -0400

> Just to clarify, unlike variable length ISAs Sparc has fixed 32bit and
> 64bit ISAs... Sparc v8+ is 32bits for every instruction executed while
> for Sparc v9 it is 64bits for every instruction.

Instructions are 32-bits in size, regardless of "mode".

Re: Please upgrade your machines to sparc64

[chase rayfield]

Derp... my bad goes back to read sparcv9.pdf ... admitedly I've read
though more of v8.pdf.



On Thu, Jun 23, 2016 at 3:45 PM, David Miller <davem@davemloft.net> wrote:
> From: chase rayfield <cusbrar1@gmail.com>
> Date: Thu, 23 Jun 2016 15:42:00 -0400
>
>> Just to clarify, unlike variable length ISAs Sparc has fixed 32bit and
>> 64bit ISAs... Sparc v8+ is 32bits for every instruction executed while
>> for Sparc v9 it is 64bits for every instruction.
>
> Instructions are 32-bits in size, regardless of "mode".

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 run, you should just run 
what you want.

I was just trying to make a few simple points...

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

2. No Linux distribution has a solution in place for a default mixed 
userland based on application optimization.

3. While sparc32 maybe more efficient, it would be a ton of work to go 
through the entire repository to figure out which applications should be 
compiled as sparc64 by default. vice versa, going through a sparc64 
repository to figure out which applications should be compiled as 
sparc32 by default would probably be even more work.

4. A sparc64 userland is safer than a sparc32 userland as you can 
guarantee that all applications that need more than 4GB of memory will 
get it, even if applications that don't need it receive a small 
performance penalty. A sparc32 userland would deny additional memory to 
those applications unless someone has curated the ABI assignment for the 
entire repository or the user installs the sparc64 ABI version. When it 
comes to "just working", the former is likely preferred.

As a side note, I've had this discussion many times before and the idea 
of GCC optimizing sparc code to ilp32 when possible is probably the best 
idea i've seen brought up. Maybe one day...

Re: Please upgrade your machines to sparc64

[David Miller]

From: alexmcwhirter@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

[Alexandre Chartre]

On 06/23/2016 10:38 PM, David Miller wrote:
> From: alexmcwhirter@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
>

Note that Solaris is providing more and more 64-bit binaries. Solaris
libraries are always provided as 32 and 64-bit to ensure backward
compatibility. But new Solaris binaries are usually 64-bit only.

alex.

Re: Please upgrade your machines to sparc64

[John Paul Adrian Glaubitz]

On 06/27/2016 02:38 PM, Alexandre Chartre wrote:
> Note that Solaris is providing more and more 64-bit binaries. Solaris
> libraries are always provided as 32 and 64-bit to ensure backward
> compatibility. But new Solaris binaries are usually 64-bit only.

Thank you! I hope that will finally clear things up a bit.

Adrian

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