Re: [GTALUG] life expectancy of 32-bit x86 [was Re: Fedora Netinstall] [long]

[Anthony de Boer via talk]

D. Hugh Redelmeier via talk wrote:
>  ...
> So: I don't expect that we're going to see many programs that will
> stop supporting 32-bit.  A greater risk is that 32-bit ports will
> become less tested.  That may reduce reliability.
> 
> Some distros are surely going to drop 32-bit soon.  I would imagine
> that debian won't be one of them.

Debian has already dropped 32-bit PowerPC as a release architecture;
64-bit is still supported.  And I've heard mutterings that i386 is
getting too long in the tooth and that amd64 is very much the core
architecture today.

We're already seeing browsers needing ginormous address space and not
playing nicely on smaller computers with less than four gig in which to
romp.  I'm expecting that 64-bit processors are going to become
increasingly less optional in the desktop and server space, and that
there may be a fork at some point with the full distros focussing on
64-bit and embedded distros being the thing to use on 32-bit hardware.

64-bit ARM has been awfully slow off the mark but is likely to be a big
thing once it gets properly going.  The only reasonable thing I've seen
actually for sale and have personally touched and run is the Solidrun
Macchiatobin.  Decent little board, supports a proper DIMM-load of RAM,
the 10gig SFP slots are overkill for most of us but it has a normal GigE
port too.  I haven't tried video but I've heard reports of people having
luck with a card of the appropriate PCI flavour.

(Technically you can boot arm64 on some Raspberry Pis, but they don't
have enough RAM to make that worth trying.)

-- 
Anthony de Boer
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] life expectancy of 32-bit x86 [was Re: Fedora Netinstall] [long]

[Lennart Sorensen via talk]

On Wed, Feb 14, 2018 at 08:56:54PM -0500, Jamon Camisso via talk wrote:
> I think you can buy Cavium ThunderX systems if you get in touch with the
> distributor in Canada. We have some of their systems in the US for arm64
> build farm purposes.

I think now you can, but even a year or two ago, good luck.

I think the most powerful I managed to get my hands on was an 8 core
64bit A53 reference board from Freescale (NXP?  Qualcomm?) but that was
a pain to try to work with because the network ports were totally weird
and non standard and kernel support was not integrated yet.

> But yes, the long promised ARM in the datacentre thing seems to remain
> just that, a promise with no major channel resellers or anyone offering
> much in terms of product.
> 
> HP tried high density ARM servers with its Moonshot blades, but it seems
> like that effort died off in 2014 as soon as it started, and the whole
> HP/HPE thing the next year probably didn't help.

Also a box full of independant small 32 bit arm servers was not what
people wanted.  They wanted large single image multicore 64 bit arm
servers.

-- 
Len Sorensen
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] life expectancy of 32-bit x86 [was Re: Fedora Netinstall] [long]

[Jamon Camisso via talk]

On 2018-02-14 11:06 AM, Lennart Sorensen via talk wrote:
> If it was actually possible to buy arm servers I think at least some
> people would have (I know I would have in the past), but none of the
> systems announced could actually be bought unless you were google or
> facebook or something like that.

I think you can buy Cavium ThunderX systems if you get in touch with the
distributor in Canada. We have some of their systems in the US for arm64
build farm purposes.

But yes, the long promised ARM in the datacentre thing seems to remain
just that, a promise with no major channel resellers or anyone offering
much in terms of product.

HP tried high density ARM servers with its Moonshot blades, but it seems
like that effort died off in 2014 as soon as it started, and the whole
HP/HPE thing the next year probably didn't help.

Cheers, Jamon
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] life expectancy of 32-bit x86 [was Re: Fedora Netinstall] [long]

[Stewart C. Russell via talk]

On 2018-02-11 01:06 PM, D. Hugh Redelmeier via talk wrote:
> 
> - irrelevant aside: many 64-bit ARM SOCs don't support more than 2G or
>   3G of RAM.  This seems crazy to me since the first use-case of
>   64-bit is to support wider pointers.

Most ARMs are just application processors. If you're building a set-top
box, you don't want to pay for all of those extra address lines you'll
never use. While it's not about the RAM, Chris Tyler at Seneca gives an
interesting talk about how 64-bit ARM does some rather clever
vectorization by working with 128-bit vectors internally.

I'm guessing the demand for ARM as anything other than application
processor isn't there yet. Witness AMD's Opteron A1100: production has
been scaled back, possibly even stopped. In theory you can still get a
$600 A1100 dev box from SoftIron, but it's not readily available.

> Almost NO 32-bit x86 chips are in current production.  I think that
> Intel has some goofy SoCs for IoT applications that are limited to
> 32-bit but they really don't matter.

No, they canned that line last year. They really were not very good.

 Stewart
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk

[GTALUG] life expectancy of 32-bit x86 [was Re: Fedora Netinstall] [long]

[D. Hugh Redelmeier via talk]

| From: Bob Jonkman via talk 

| I'm already using IceCat, so the browser isn't my problem. But the
| lack of 32-bit Chrome is the thin edge of the wedge. There will be
| other packages that will no longer be distributed for 32-bit
| architecture. Then what?
| 
| But I guess we're not using 8-bit and 16-bit CPUs any more either.

The difference between 8, 16, and 32 were serious and a programmer had
to be aware of them.  64k limits would impinge fairly often.

The difference between 32 and 64 are important, but only for a small
number of cases.  Handling a lot of memory is best done with pointers
that are wide enough.

There are two kinds of pointers: ones that hold a physical address (to
real memory) (used by the OS), and ones that hold a virtual address
(used by the OS and by userland programs).

- on x86, the PAE feature allows the OS to use more than 3.5G of
  physical memory.  I don't know about other 32-bit architectures.

  (Early Atom processors only sent 32-bits worth of address lines
  off-chip, even though they had PAE.  I have an Atom desktop PC with
  4G of RAM that can only use 3.5G of it.  I consider this an example
  of monopolistic behaviour.  It was not easy to find this limitation
  documented.)

- on 32-bit machines, Linux processes cannot easily use more than 3G
  of address space.  If you want more, you write code to manage your
  address space, but that is intrusive and intricate.  Why not just go
  to 64-bit instead?

- irrelevant aside: many 64-bit ARM SOCs don't support more than 2G or
  3G of RAM.  This seems crazy to me since the first use-case of
  64-bit is to support wider pointers.

- wider external data busses improve performance but they are not tied
  to the instruction-set data-width.  x86 busses have been 64-bits
  wide long before AMD64.  I would guess that most ARM SOCs use 16-bit
  data busses, whether they have 32- or 64-bit instruction sets.

- when you switch from 32-bit to 64-bit, programs require more memory.
  Both for object code and for data.  The x86 => x86_64 bloat was
  remarkably modest.  For ARM it seems to be a lot worse.  On SPARC
  and Power, I understand that almost all userland code is still
  32-bit, probably for this reason.

  If the penalty is significant, it makes sense to keep most programs
  32-bit.  Most standard UNIX utilities were coded in a 16-bit world
  so 32-bits should not cramp their style.

- most programmers don't think enough about overflow.  And only a few
  programming languages help.  If you programmed much for 16-bit
  machines, you do think more about overflow.  On 64-bit machines, few
  things will overflow.  Summary: 64-bit machines are more forgiving
  of sloppy programming.

What really needs more than 3G of address space?

- programs that map the whole of a very large file into the address
  space

- programs that manage scads of buffering.  Perhaps database programs
  dealing with large databases at high speed.

- programs that grew very very very large.  Or problems that grew very
  very very large.

  It seems inexcusable that browsers are starting to tick these boxes.

Almost NO 32-bit x86 chips are in current production.  I think that
Intel has some goofy SoCs for IoT applications that are limited to
32-bit but they really don't matter.

So: I don't expect that we're going to see many programs that will
stop supporting 32-bit.  A greater risk is that 32-bit ports will
become less tested.  That may reduce reliability.

Some distros are surely going to drop 32-bit soon.  I would imagine
that debian won't be one of them.

In the Microsoft world, 32-bit could be turned off at any time, at the
whim of Microsoft.  It costs them a fair bit to support 32-bit SKUs.
---
Talk Mailing List
talk@gtalug.org
https://gtalug.org/mailman/listinfo/talk