RPi Benchmarks: 32- Vs 64-bits article on HaD

[chwe]

@chwe
Well then. You seem to know how to maintain images and make sure the packages on the repos work. Make us a fully working 64 bit, Debian based Raspbian image and make sure it's as stable as the official one

why should I? I am already a spare time 'linux on armboards' maintainer.. mostly for ARM SBCs I'm more interested than the RPi. And
even then it wouldn't be a 'Raspbian' that's the RPF/RPT peoples thing. The Raspian maintainers and I have quite some differences in what we prioritize so better we keep our projects independent from each other.

[PeterO]

@chwe
Well then. You seem to know how to maintain images and make sure the packages on the repos work. Make us a fully working 64 bit, Debian based Raspbian image and make sure it's as stable as the official one

why should I? I am already a spare time 'linux on armboards' maintainer.. mostly for ARM SBCs I'm more interested than the RPi. And
even then it wouldn't be a 'Raspbian' that's the RPF/RPT peoples thing. The Raspian maintainers and I have quite some differences in what we prioritize so better we keep our projects independent from each other.

And yet you seem keen to keep telling them what they should be doing. "Put up or shut up" comes to mind.....

PeterO

[jamesh]

@chwe
Well then. You seem to know how to maintain images and make sure the packages on the repos work. Make us a fully working 64 bit, Debian based Raspbian image and make sure it's as stable as the official one

why should I? I am already a spare time 'linux on armboards' maintainer.. mostly for ARM SBCs I'm more interested than the RPi. And
even then it wouldn't be a 'Raspbian' that's the RPF/RPT peoples thing. The Raspian maintainers and I have quite some differences in what we prioritize so better we keep our projects independent from each other.

Odd, we don't tell you how to run your project, and yet you seem insistent of telling us how to run ours.

Worth remembering that our priorities are almost certainly different. We are a the world largest seller of SBC's, with a huge number sold in to commercial environments, homes, industry etc, which is certainly going to have a different set of priorities to whatever you do. Many people demanding features or telling us what we should be doing fall in to the same trap, that of thinking that we have the same goals as they do. We don't.

[Lewis-H]

Both ARM and Intel (or really, AMD, since Intel abandoned their own 64bit attempt and licensed AMD’s) took the opportunity to use the 64bit conversion to fix some long standing issues. A bunch of stuff was going to break for backwards compatibility when in 64bit mode, so might as well go all in. Those new instructions and expanded registers are where most of the benefit comes from.

Of course, the two made different decisions in the process, so they aren’t directly comparable.

[pica200]

And yet x86_64/AMD64 is still pure bloat. Eventually Intel and AMD will hit the physical limits (we are already pretty close) where the only improvements will be better CPU designs and more cores. That's when ARM and RISC-V will shine because they are fresh designs without any of the legacy bloat.

[dickon]

Code: Select all

clz

And that's *not* cruft..?

[jahboater]

And yet x86_64/AMD64 is still pure bloat. Eventually Intel and AMD will hit the physical limits (we are already pretty close) where the only improvements will be better CPU designs and more cores. That's when ARM and RISC-V will shine because they are fresh designs without any of the legacy bloat.

What is this bloat you keep referring to?

Here are the sizes of the same program, compiled with the same compiler, and the same optimization settings:-

A32: 70KB
A64: 63KB
x64: 60KB

a86_64 is the most compact. No bloat there.
There are many short instructions, for example the common "ret" instruction to return from a function is one byte (0xC3), it is four bytes on RISC.
There are larger instructions, usually in the newer AVX512 instruction sets, but they are hugely powerful and RISC CPU's have no equivalent.

[dickon]

The bloat is in the instruction coding and on the silicon. You'd expect a RISC program to be bigger as it should take more instructions to do the same thing. When you have an encoding as ludicrous as the x86 instruction encoding -- see http://www.c-jump.com/CIS77/CPU/x86/lecture.html and the like for details -- you have serious amounts of cruft. It *really* isn't pretty.

[jamesh]

Worth noting that when you work out performance/power/die area, you get similar figures for all the architectures, including ARM, so as ARM approaches x86 in performance you will find it taking similar die area. ie you need comparable numbers of transistors to get comparable performance., irrespective of the architecture. And comparable transistors also means comparable power requirements.

[jahboater]

you have serious amounts of cruft.

Please show me an actual example of an instruction exhibiting all this cruft?

The only thing really annoying about x86 is that many of the 2-byte opcodes are taken up by the x87 floating point which is now considered "legacy" (superceded by SSE and AVX). They would be better used for other more common insns.

[dickon]

Well, start at page 2-8 in volume 2A of https://www.systutorials.com/go/intel-x ... ce-manual/ and work forwards. None of it is pretty. Instruction prefixes with bits to add to other bits within the rest of the instruction to form a complete index is hardly clean. The whole microarchitecture is riddled with this sort of nonsense, which is why Intel attempted to dump it in the '90s, and why they more or less managed to in the '00s by reimplementing the whole mess as microcoded RISC instructions. It's a bit of an irony that Intel's x86 is actually quite a nice, fast RISC core with a ghastly translation layer bolted on top.

We're wildly off-topic at this point. For the sake of JamesH's blood pressure, I'm not going to comment further.

[jamesh]

Well, start at page 2-8 in volume 2A of https://www.systutorials.com/go/intel-x ... ce-manual/ and work forwards. None of it is pretty. Instruction prefixes with bits to add to other bits within the rest of the instruction to form a complete index is hardly clean. The whole microarchitecture is riddled with this sort of nonsense, which is why Intel attempted to dump it in the '90s, and why they more or less managed to in the '00s by reimplementing the whole mess as microcoded RISC instructions. It's a bit of an irony that Intel's x86 is actually quite a nice, fast RISC core with a ghastly translation layer bolted on top.

We're wildly off-topic at this point. For the sake of JamesH's blood pressure, I'm not going to comment further.

Considering the two mad as frogs people who turned up yesterday and had to be dealt with, this thread is a paragon of virtue.

[dickon]

I think I only saw the one. Nice chap...

[chwe]

@chwe
Well then. You seem to know how to maintain images and make sure the packages on the repos work. Make us a fully working 64 bit, Debian based Raspbian image and make sure it's as stable as the official one

why should I? I am already a spare time 'linux on armboards' maintainer.. mostly for ARM SBCs I'm more interested than the RPi. And
even then it wouldn't be a 'Raspbian' that's the RPF/RPT peoples thing. The Raspian maintainers and I have quite some differences in what we prioritize so better we keep our projects independent from each other.

Odd, we don't tell you how to run your project, and yet you seem insistent of telling us how to run ours.

Worth remembering that our priorities are almost certainly different. We are a the world largest seller of SBC's, with a huge number sold in to commercial environments, homes, industry etc, which is certainly going to have a different set of priorities to whatever you do. Many people demanding features or telling us what we should be doing fall in to the same trap, that of thinking that we have the same goals as they do. We don't.

and that's why I would never release a 'Raspbian' or somehow Raspbian affiliated OS for the RPi. And it's completely fine that you have other priorities just don't expect that I'll change mine only cause the 'largest and whatever argument you always come up to justify your decision"-SBC maker things I should.
But arguing that thousands of packets have to be recompiled for '64 bit Raspian' is wrong, it's a Debian supported architecture. Obviously you've to deliver multiple images if you want to provide a 64bit userland cause they won't run on Pi1 and Pi Zero and early versions of Pi2 but that's not something that will change if you release a wip yet or in 2 years.. all those RPis don't turn magically into 64 bit devices. So the only reason I see valid why there's no WIP version of a 64bit raspbian is that some drivers (e.g. camera etc) are not ready yet. And here I'm arguing that if you're honest what works and what doesn't this isn't a big deal. 64bit wont fit perfect with better performance for every use-case.. so does 32bit raspian neither..

But I might bookmark this answer for all further support questions when people ask why our project doesn't support the Raspberry Pi..

And yet x86_64/AMD64 is still pure bloat. Eventually Intel and AMD will hit the physical limits (we are already pretty close) where the only improvements will be better CPU designs and more cores. That's when ARM and RISC-V will shine because they are fresh designs without any of the legacy bloat.

wrong topic, it's about software not hardware.. but with all the other IP blocks besides CPU, IMO arm SoCs tend to be a nightmare when it comes to legacy code to support hardware features.. But even then.. wrong topic..

[ejolson]

But I might bookmark this answer for all further support questions when people ask why our project doesn't support the Raspberry Pi.

If this thread is to serve as the definitive reference for why Raspbian is not 64-bit, then it is worth noting that the data bus to RAM on the 4B is only 32-bits wide. This means that saving and restoring 32-bit registers is noticeably faster than 64-bit registers unlike other hardware designs.

While tests show performance gains in select benchmarks, the improvement is not uniform and some applications show slowdowns due to the 32-bit memory bandwidth constrains. One popular program which experiences a slowdown in 64-bit mode is the Python language interpreter. While a rewrite that forces 32-bit index fields in the Python object system could remedy this, it is highly unlikely that will happen.

In a way, installing 64-bit Debian directly using build root from the official Debian package repositories is more official than Raspbian. From a practical point of view the main advantage is that each official Debian repository is maintained with security updates for a much longer period than the corresponding ones in Raspbian. In the data center as well as some areas of education, the information-technology support team does not want to spend time replace operating systems unless the hardware is replaced as well.

Operating-system updates available until end of life for the hardware can also be important when using the Pi in long-lived behind-schedule projects such as the next universal all-purpose F-plane, though the unstable Debian branch could be helpful in this case as well.

[jamesh]

But arguing that thousands of packets have to be recompiled for '64 bit Raspian' is wrong, it's a Debian supported architecture. Obviously you've to deliver multiple images if you want to provide a 64bit userland cause they won't run on Pi1 and Pi Zero and early versions of Pi2 but that's not something that will change if you release a wip yet or in 2 years.. all those RPis don't turn magically into 64 bit devices. So the only reason I see valid why there's no WIP version of a 64bit raspbian is that some drivers (e.g. camera etc) are not ready yet. And here I'm arguing that if you're honest what works and what doesn't this isn't a big deal. 64bit wont fit perfect with better performance for every use-case.. so does 32bit raspian neither..

I'm not arguing that. There's no point in recompiling a load of stuff if Debian (or even Ubuntu) already have it, that would be a complete waste of time and money. Multiple images will be necessary of course, and you are correct in that there are still drivers missing that need to work in 64bit. Cameras is one, LCD drivers another, KMS still not quite ready for prime time and some others. All stuff that can and will be fixed. Not sure what is different now than at any time in the past. We've never said we won't be doing a 64bit raspbian, we've just never said when, and have given reasons why.

[dickon]

And it's worth pointing out that if you don't need any of the Pi- or Raspbian-specific bits -- camera, video codec blocks etc. -- then plain Debian is more or less the same thing, and a bit quicker on 32b due to the later ARM revision it targets. I generally use the Raspbian kernel with a Debian userland on most of my Pis.

[jamesh]

Worth considering that if we release a Raspbian that is actually not as good as a previous version (ie with loads of stuff missing), we get a HUGE amount of negative press - it really doesn't matter how many times you say its a BETA or is missing stuff we are still working on, we have enough detractors that they would have a field day. Look at the nonsense over the USB-C power, affected very few people yet we STILL have people coming along saying they haven't bought yet, even though it would never have affected them. All caused by a few bad actors looking for clicks. It takes a long time to recover a reputation, even one lost for invalid reasons, so it's actually better to wait until you have all your bottles in a row rather than release something half finished.

[Heater]

jamesh is right there.

In the software world if you change one little, teeny, weeny thing, all kind of stuff that depends on that breaks.

That cascades into endless questions here and elsewhere as to why X or Y or Z no longer works. See Stackoverlow or any support forum anywhere to see that in action every day.

Only yesterday I experienced this in following the getting started pages of Nvidia's Jetson Nano board.

Well, that is OK for me, I can raise an issue on github, discuss the issue with the developers and the problem is fixed soon enough.

Now scale that up to 30 million users upgrading to some 64 bit Raspbian. For sure there will be an avalanche of chaos and confusion.

This mammoth change is not to be undertaken lightly.

[rpdom]

As to whether we need a 64-bit Raspbian with all/many packages recompiled, or just use the standard DEbian ARM64 packages with some Raspberry Pi add-ons, well, one of the things about the original Raspbian is that a lot of work was put into speeding it up by optimizing various critical libraries, like the copy/fill routines which were not very efficient in the original Debian sources. Hopefully those changes made it back upstream. There may indeed be other improvements that could be made in the ARM64 code, but I suspect that if that happens they will be passed back upstream.

There will almost certainly be a small number of packages that will be rebuilt with Pi specific mods, but they will be available from the archive.raspberrypi site.

[pica200]

Regarding x86_64/AMD64:
Yes, i'm talking about the hardware here. The silicon. It needs silly amounts of transistors and still has the legacy bloat from the x86 days in silicon. They can't just remove anything like ARM does for compatibility reasons so they have to keep stacking the steaming piles on top and so it becomes messy. When it comes to efficiency RISC clearly wins right now. It's not just about code size. And yes, ARM will get more complex but they still have the freedom of removing or changing features which is a major advantage in my opinion (not so much for compiler and software devs).

@dickon
What's wrong with the clz instruction? It saves many cycles and fits pretty well in the ARM instruction set. If this is cruft to you what is "fjcvtzs" (a dumb AArch64 instruction in my opinion) then?


More on-topic:
Another reason you can't just use Debian ARM64 was Mesa. I don't know if this has been solved yet but Mesa in the Debian repos was too old to support the Video Core VI. There are likely more such cases. And even if it catched up enough you may end up with outdated versions with all kinds of bugs.

[jamesh]

Regarding x86_64/AMD64:
Yes, i'm talking about the hardware here. The silicon. It needs silly amounts of transistors and still has the legacy bloat from the x86 days in silicon. They can't just remove anything like ARM does for compatibility reasons so they have to keep stacking the steaming piles on top and so it becomes messy. When it comes to efficiency RISC clearly wins right now. It's not just about code size. And yes, ARM will get more complex but they still have the freedom of removing or changing features which is a major advantage in my opinion (not so much for compiler and software devs).

@dickon
What's wrong with the clz instruction? It saves many cycles and fits pretty well in the ARM instruction set. If this is cruft to you what is "fjcvtzs" (a dumb AArch64 instruction in my opinion) then?


More on-topic:
Another reason you can't just use Debian ARM64 was Mesa. I don't know if this has been solved yet but Mesa in the Debian repos was too old to support the Video Core VI. There are likely more such cases. And even if it catched up enough you may end up with outdated versions with all kinds of bugs.

We have spent a lot of time and money on getting Mesa up and running and you should find it works pretty well on the Pi4. Still work ongoing (At Igalia), and its all being backaported to earlier models where possible.

[pica200]

Just saying. That was not an insult to the work of RPiT. Vanilla Debian repos are slow to get updates so it may not be as up -to-date as Raspbian and lacks some improvements as a result.

[dickon]

@dickon
What's wrong with the clz instruction? It saves many cycles and fits pretty well in the ARM instruction set.

It seems broadly pointless, and definitely not RISC. ARM doesn't have a strlen() instruction (unlike x86); I'm not sure why it needs to have an instruction to do something I've never needed to do. I've subsequently been advised that it has some significant uses in crypto, but it still seems niche to me.

If this is cruft to you what is "fjcvtzs" (a dumb AArch64 instruction in my opinion) then?

Dear gods. I had no idea. Kill it with fire.

[jahboater]

What's wrong with the clz instruction?

Its the "bsr" (bit scan reverse) instruction on x86 by the way.