User avatar
John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

RIP 32 BIT

Thu Jul 04, 2019 1:05 am

Ubuntu Mint dropping 32 bit
64-bit CPUs have been around longer than Ubuntu has
When was the last time you bought a 32 bit PC?

What do you miss most not having a 64 bit OS on the RPi?

Andyroo
Posts: 3756
Joined: Sat Jun 16, 2018 12:49 am
Location: Lincs U.K.

Re: RIP 32 BIT

Thu Jul 04, 2019 1:30 am

What do I miss?

Nothing but then I’m happy to work within the limits of the machine as it is. If I need a bigger machine, the Mac gets used.

It will come at some point but at the moment the support team have other things on their hands to look at first and you are still limited by hardware as you cannot throw memory into these boxes.

It’s pointless stirring this up again and again - it leads to threads being locked and moderators getting miffed.
Need Pi spray - these things are breeding in my house...

Heater
Posts: 12953
Joined: Tue Jul 17, 2012 3:02 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 2:23 am

That is a non question.

I do have a 64 bit OS on my Pi. It's Pi64, basically Debian for the Pi. There are others to chose from.

Anyway CPU's are like shoes. You buy the ones that fit.

For all my serious uses of a PI 32 bits is more than enough.

I also use 8 and 16 bit machines where appropriate.

User avatar
John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: RIP 32 BIT

Thu Jul 04, 2019 2:36 am

The RPi 4 B is a new ball game with 4GB and a faster processor. My guess is a blessed 64 bit OS for the RPi isn't too far off in the future.

It gets expensive fast trying to maintain a custom configured OS distribution. The reason and limitations are no longer a factor to justify investing in 32 bit on a mainstream level.

Heater
Posts: 12953
Joined: Tue Jul 17, 2012 3:02 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 2:50 am

I think you are right.

This has been discussed in so many threads now that new one on the same speculation get locked almost immediately.

User avatar
Imperf3kt
Posts: 2527
Joined: Tue Jun 20, 2017 12:16 am
Location: Australia

Re: RIP 32 BIT

Thu Jul 04, 2019 3:09 am

Calm down, you've got until 2038 before you need to say goodbye to 32bit
Last edited by Imperf3kt on Thu Jul 04, 2019 4:37 am, edited 1 time in total.
55:55:44:44:4C
52:4C:52:42:41

User avatar
Gavinmc42
Posts: 3407
Joined: Wed Aug 28, 2013 3:31 am

Re: RIP 32 BIT

Thu Jul 04, 2019 3:44 am

One of the problems with kernels and compilers is the hardware needed to compile them is normally bigger than Pi's.
Till now. The Pi4 with 4GB and running 64bit OS should be able to make 32 or 64bit kernels etc.
It might be a bit slow so buy another few and have a network of compiler boxes.

Pi4B4 and 64bit OS is real desktop territory, it makes many more things possible.
Like using this
https://www.designnews.com/electronics- ... 5038959945
lucky I have some microHDMI cables and adapters now ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RIP 32 BIT

Thu Jul 04, 2019 4:05 am

32-Bit rules, especially when talking ARM.

With the ARM MMU you have up to 16TB (Terra Bytes) of address space on a 32-bit ARM, limited only by how many address lines the MMU implementation implements (like the 35 effective of the Raspberry Pi4B and 3B, giving a max of 32GB).

If I ever need more than 16TB of RAM something is wrong. If I ever need to have more than 3.8GB Mapped in to a single applications work space at one time then something is wrong.

As to the advantage in some math for 64-bit, well truth is that it is uncommon enough that it is really just a waste of memory for 99.99% of applications. For that matter about 45% of applications could do just as well with only 16-bit integer math and logic, though that is a small enough number to justify 32-bit. 0.001% of applications does not justify 64-bit.

That is just my view, take it or leave it.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 12953
Joined: Tue Jul 17, 2012 3:02 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 5:25 am

@Imperf3kt,
Calm down, you've got until 2038 before you need to say goodbye to 32bit
Not so. I was already bitten by 32 bit processors and working with time five years ago.

I was trying to create security certificates with OpenSSL. The certificates were created but did not work in my VPN. After a day or two of investigation I found my certs we being created with an expiry date some time in the past. They were created expired! I gave up messing with that, but some time later I discovered my same procedure created valid certificates when used on a 64 bit machine. After more investigation back on the 32 bit machine I found that because I had set the certs to expire in 40 years time, which is after 2038, some time calculation in OpenSSL had overflowed resulting in an expiry date in the past. Sometime later I found this had been reported as a bug in OpenSSL and fixed.

@Gavinmc42,
One of the problems with kernels and compilers is the hardware needed to compile them is normally bigger than Pi's.
I have been compiling GCC, Linux kernels and a whole lot more since 1996 when 1GB of RAM was a lot!

On the Pi I set up a swap file on a fast media and such compilations run just fine. If a bit slowly...

@DavidS,
32-Bit rules, especially when talking ARM.
Not really. I suspect you will find all new phones and tablets are 64 bit ARM. ARM would only laugh at you if you told the they need not bother with 64 bit cores when they are doing so well with them.
With the ARM MMU you have up to 16TB ..
Show me an OS that can make us of 16TB or even 32GB of address space on a 32 bit machine. Even Raspbian on the Pi 4 need some address space extension hack (I forget what it is called) to access 3.2GB of RAM from a process. Which slows things down apparently.
If I ever need more than 16TB of RAM something is wrong. If I ever need to have more than 3.8GB Mapped in to a single applications work space at one time then something is wrong.
I guess you are just not working with big data sets. A few gigs is small for a database, being able to map a lot of data to the address space makes the DB software easier to write and faster.
For that matter about 45% of applications could do just as well with only 16-bit integer math and logic,
Where on Earth did you get that statistic from? I guess you made it up.

Pretty much nothing would work around here if numbers were limited to 16 bits.

32 bits is not even big enough to count the number of living humans. Pathetic.
That is just my view, take it or leave it.
My view is:

1) I don't care. Raspbian can stay at 32 bits forever if it likes (Not that I think it will mind). We already have other 64 bit OS options coming along quickly.

2) There are some performance gains to be had using 64 bits. Might as well make use of it, it's there for the taking.

3) I do like to use CockroachDB. It can be be hacked around to build on 32 bits, which I have done, but is much happier on 64 because then it can map the whole data set to memory space (not necessarily in memory all at once) and refer to things with regular pointers.

4) I hate the thought of all those transistors in the SoC sitting around doing nothing :)

User avatar
John_Spikowski
Posts: 1308
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: RIP 32 BIT

Thu Jul 04, 2019 5:45 am

I see Raspian following in the SyWoW64 solution to keeping 32 bit relevant in a 64 bit world.

It's not loyal application developers that can live in both environments but devices and drivers that aren't as passionate with the 32 bit bagage. (cost motivated)
Last edited by John_Spikowski on Thu Jul 04, 2019 6:18 am, edited 2 times in total.

Heater
Posts: 12953
Joined: Tue Jul 17, 2012 3:02 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 6:02 am

ScriptBasic,
I see Raspian following in the SyWoW64 solution to keeping 32 bit relevant in a 64 bit world.
Sure, why not. Raspbian is basically Debian and Debian has been able to support 32 bit binaries on 64 bit machines since forever. At least on x86, no idea how well it works on ARM but I suspect it's fine.

Turns out I almost never need to use it. All software I use is Open Source and works fine when built for 64 bits.

The only project I have heard raising serious concerns about the proposed dropping of 32 bit support in Ubuntu and the like is Wine. They have a problem with that idea because Wine needs to be able to run all those legacy 32 bit Windows executables people seem to be attached too.

Actually you can write new code using the old Win32 API and build it on Linux using libWine. Works a treat. They don't want to lose that capability.

Wine is not really a concern for Raspbian as it does not work on ARM anyway.

User avatar
Gavinmc42
Posts: 3407
Joined: Wed Aug 28, 2013 3:31 am

Re: RIP 32 BIT

Thu Jul 04, 2019 6:17 am

I hate the thought of all those transistors in the SoC sitting around doing nothing :)
I agree, I paid for them, I want them working hard for me.

I compiled the RISC_V toolset on a Pi3B+, 13hrs.
Once I have a 4B4 and a decent USB3.0 drive I will see how fast it goes :D

All those browser guys, Android etc are going 64bit only.
Yes, bloatware code but hey we can run that now on the 4's :lol:

I just want the Pi4 as desktop I can use for developing anything, that includes 4bit to 64bit.
Or any other number of bits I want on a FPGA.
Some people are saying 8 bits is enough for ML/AI stuff, make a bunch of 8it cpu is in a FPGA?
or even 4 bit CPU's working on 8bit data?

For RPF's mission why bother with 64bit, someone will do it sooner or later for them.
RPF is not in the OS distribution business, that is secondary.
One day those BCM2835's will go obsolete, they will probably have a 16nm 64bit replacement ready?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 4585
Joined: Wed Feb 04, 2015 6:38 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 6:52 am

Heater wrote:
Thu Jul 04, 2019 5:25 am
2) There are some performance gains to be had using 64 bits. Might as well make use of it, it's there for the taking.
These gains might be more than expected on the Pi4.

In 64-bit mode it runs a different instruction set. One of the reasons for the new ISA was to make it suitable for modern
out-of-order high performance CPU cores.

The Pi3 CPU's were simple in-order Cortex-A53's.
The Pi4 CPU's are modern out-of-order superscalar CPU's, Cortex-A72, the sort of thing A64 was designed for.

So I think the speed up should be more than we saw when running 64-bit code on the old A53.

The 32-bit ARM instruction set was designed long long ago before the new high performance cores were even a pipe dream. Features like being able to randomly write to the IP, conditional execution of almost anything, etc are just bad news nowadays.

Also an LPAE kernel would not be required.

Any benchmarks should be done with code compiled for the A72 (-mcpu=cortex-a72 -mtune=cortex-a72).
Last edited by jahboater on Thu Jul 04, 2019 7:07 am, edited 1 time in total.

User avatar
Gavinmc42
Posts: 3407
Joined: Wed Aug 28, 2013 3:31 am

Re: RIP 32 BIT

Thu Jul 04, 2019 7:07 am

Going to be interesting to see how the code compiled for A72 compares to the A53?
Which is the best compiler to use?
We actually need two 64bit OS's?
My head hurts.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jahboater
Posts: 4585
Joined: Wed Feb 04, 2015 6:38 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 7:11 am

Gavinmc42 wrote:
Thu Jul 04, 2019 7:07 am
We actually need two 64bit OS's?
Its common to mix high power Cortex-A72's or A73's with the low power A53's in the same SoC - called big.little

Processes are moved around between the big and the little cores all the time.

Clearly they must be compatible, but the question arises should the app be compiled for the A53 or for the A72? I think the answer is to compile for the big A72 cores. The differences are mostly scheduling.

User avatar
Gavinmc42
Posts: 3407
Joined: Wed Aug 28, 2013 3:31 am

Re: RIP 32 BIT

Thu Jul 04, 2019 7:23 am

big.little is common on those Octocore phones etc, but we have 4 x A72 on the Pi4 and 4 x A53s on the 3B's.
Not sure if the A72 have extra instructions that can speed things ups?
A53 code on the Pi4 will run faster anyway at 1.5GHz instead of 1.4GHz.
Some guys are saying 1.75GHz overclocking :o

Time to check A72 datasheets, what are their improvements?
Edit, hmm bigger L2 cache and about 2.5 times the performance, so with the extra clock speed about 3 times faster.
No idea what that out of order stuff is needed for?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
bensimmo
Posts: 4121
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: RIP 32 BIT

Thu Jul 04, 2019 7:55 am

It'll be needed more when programs are not supported on 32bit OSs, iirc Node-Red left it behind quite a lot of version ago?
At least while trying to install it and it always failing.

The kernel will go 64bit, but that is easier.
The OS itself will either need two different versions (if they can get the support and ease the process between them).
They could perhaps drop Desktop Support from the Zero and Pi1 (original 2) series and just support 'lite', less to worry about.

The 4B will need to be established properly by then so that the 3B/4B is the desktop.

Anyway. Programs they want that need it.

jahboater
Posts: 4585
Joined: Wed Feb 04, 2015 6:38 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 7:55 am

Gavinmc42 wrote:
Thu Jul 04, 2019 7:23 am
Not sure if the A72 have extra instructions that can speed things ups?
I think the two ISA's are completely compatible. I have compiled large programs for the A72 and run them on the A53 and vice-versa.
No idea what that out of order stuff is needed for?
If you have "a = b + c" and then "d = a + 4", the second addition has to wait for the first to complete, so that a value for "a" is available..
The compiler will normally insert extra unrelated instructions in between to allow time for the first addition to complete.
A modern out-of-order CPU like the A72 will itself continue executing other instructions while it waits for the dependency to be satisfied. The CPU should not "stall". The scheduling is very different.

Heater
Posts: 12953
Joined: Tue Jul 17, 2012 3:02 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 8:26 am

jahboater,
These gains might be more than expected on the Pi4. In 64-bit mode it runs a different instruction set ...
Yep. ARM cleaned things up and made the ISA more performance friendly. Basically they learned lessons from their mistakes, and the mistakes of other RISC vendors (MIPS had pipeline delay slots that the programmer/compiler had to think about to get performance, which did not work out). They learned the same lessons that Berkeley did and have put to use in the RISC V ISA design.
The 32-bit ARM instruction set was designed long long ago before the new high performance cores were even a pipe dream.
Something may have been a dream but the original ARM was focused on performance. The performance one could get from going to a RISC architecture. It was the fastest processor one could get in a desktop computer at the time. But as you say, lessons have been learned over the decades.
Features like being able to randomly write to the IP, conditional execution of almost anything, etc are just bad news nowadays.
Ha! I bet DavidS will have something to say about that. He'd be wrong mind.

That Big-Little things seems like an insane nut job idea to me. Adding complexity were there need not be any.

If you want a couple of low power cores for background tasks while the user is not surfing Facebook I'm willing to bet it could be done in 64 bits with the same ISA. Just build those low power cores without the go faster goodies, no pipelining, no branch prediction, no out of order execution, no hardware multiply, etc. Oh and slow the clock down by a factor of 10 or whatever. Then you can migrate the same 64 bit binaries from fast to slow cores with no noticeable difference but the speed. Could be done easily with a RISC V ISA, why not ARM?

Note to self: I must build a 64 bit version of my home made RISC V design to see how many more logic elements it takes up in my FPGA.

Heater
Posts: 12953
Joined: Tue Jul 17, 2012 3:02 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 8:33 am

Gavinmc42,
No idea what that out of order stuff is needed for?
Think about going to the supermarket with your wife's shopping list. You probably hate shopping as much as I do so you want to get it done as fast as possible and get out of there.

Mostly you find that the items on the shopping list are not in the order than you will find them as you traverse the isles of the supermarket. To get them in the order listed would be very slow going and involve a lot of walking back and forth picking things up.

Being smart you optimize your tour of the supermarket. You make one trip around the isles and pick things up that are on the list as you come to them.

Bingo, you are out of the supermarket many times faster than doing it the in order way. You have optimized your shopping.

That is what out of order execution is all about :)

jahboater
Posts: 4585
Joined: Wed Feb 04, 2015 6:38 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 8:42 am

Heater wrote:
Thu Jul 04, 2019 8:26 am
If you want a couple of low power cores for background tasks while the user is not surfing Facebook I'm willing to bet it could be done in 64 bits with the same ISA.
It can be done, and is. The A53 runs 64-bit A72 targeted binaries.
Heater wrote:
Thu Jul 04, 2019 8:26 am
Just build those low power cores without the go faster goodies, no pipelining, no branch prediction, no out of order execution, no hardware multiply, etc.
Exactly. The A53 is designed for low power consumption and efficiency. (But it does have hardware multiply and divide which I think might save power compared to slow library functions).
Heater wrote:
Thu Jul 04, 2019 8:26 am
Oh and slow the clock down by a factor of 10 or whatever. Then you can migrate the same 64 bit binaries from fast to slow cores with no noticeable difference but the speed.
Oddly, for my Odroid-N2 which is 4 x A73 (big) cores and 2 x A53 (little) cores, the big cores run at 1.8GHz and the little cores run at 1.9GHz. Not sure why that is.
Whenever I look at "top", I see Linux chooses big cores to execute my tasks, unless I have done something like "make -j6".
Last edited by jahboater on Thu Jul 04, 2019 8:55 am, edited 2 times in total.

jahboater
Posts: 4585
Joined: Wed Feb 04, 2015 6:38 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 8:53 am

Heater wrote:
Thu Jul 04, 2019 8:33 am
That is what out of order execution is all about :)
Now its done by the hardware, whereas before it was done by the compiler.

Good luck implementing that in your FPGA :)

jahboater
Posts: 4585
Joined: Wed Feb 04, 2015 6:38 pm

Re: RIP 32 BIT

Thu Jul 04, 2019 9:18 am

Heater wrote:
Thu Jul 04, 2019 8:26 am
Yep. ARM cleaned things up and made the ISA more performance friendly.
You can image how hard conditional execution is to implement in an out-of-order CPU.
But also it freed up 4 bits in the instruction word. One bit is needed to say if the operands are 32 or 64 bits wide, the other three bits allowed double the number of registers (three operands) which makes a huge difference.

hippy
Posts: 5568
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: RIP 32 BIT

Thu Jul 04, 2019 9:28 am

bensimmo wrote:
Thu Jul 04, 2019 7:55 am
It'll be needed more when programs are not supported on 32bit OSs
Indeed. The most compelling argument for 64-bit is that others have jumped on the 64-bit bandwagon leaving 32-bit no longer supported.

Most of the arguments that one has to move to 64-bit, to allow access to more than 4GB of memory, to be able to handle 64-bit data, are utterly wrong. Many claimed advantages and benefits from moving to 64-bit are over-stated.

64-bit is undoubtedly the future, but mostly because the hype would have it that 32-bit cannot be.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RIP 32 BIT

Thu Jul 04, 2019 10:30 am

Heater wrote:
Thu Jul 04, 2019 5:25 am
@Imperf3kt,
Calm down, you've got until 2038 before you need to say goodbye to 32bit
Not so. I was already bitten by 32 bit processors and working with time five years ago.

I was trying to create security certificates with OpenSSL. The certificates were created but did not work in my VPN. After a day or two of investigation I found my certs we being created with an expiry date some time in the past. They were created expired! I gave up messing with that, but some time later I discovered my same procedure created valid certificates when used on a 64 bit machine. After more investigation back on the 32 bit machine I found that because I had set the certs to expire in 40 years time, which is after 2038, some time calculation in OpenSSL had overflowed resulting in an expiry date in the past. Sometime later I found this had been reported as a bug in OpenSSL and fixed.
That's a bug in OpenSSL, nothing to do with whether the machine itself was 32 or 64bit.
And the internal clocks in the kernel have been fixed for many a year to handle >2038, with userspace APIs to match.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Off topic discussion”