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

[chwe]

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.

I don't get how people come from "a 64 bit raspian" would be nice to it must be possible to upgrade from your current 32 bit system. Obviously this ain't and IMO shouldn't gonna happen...

I'm not arguing that.

I don't only argue against you here.. fyi it came from this one:

It's not just a case of two images. There's also the tens of thousands of packages in the repositories to build and take up storage on all the mirrors around the world.

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.

that argument would be a way better if you don't bring then a hardware example.. and for the sake of this thread I don't discuss the USB-C thing again..

All caused by a few bad actors looking for clicks.

hmm a really cynical point of view.. Obviously you doing mistakes gets more attention than *random small SBC maker does wrong*... That's the price of being the biggest player on the SBC market.. On the other side you annotating a new product also gets more media coverage than *random small SBC maker* annotates a new product.

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.

And that works for those being familiar with tweaking userlands or are enough pain resistant to learn it.. Obviously as someone who spends quite some time in getting a debian/ubuntu derivative working on arm boards, none of my arm boards run with the vendor provided stock OS, I can also quick and dirty glue something together to get what I want (e.g. 64 bit Debian with the Raspian kernel or recompile my own kernel etc.
it works for me.. but it's obviously not a solution for everyone).

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.

likely for 99% of all debian packaged it doesn't matter if you get them from the Raspian repo or the debian repo in terms of which version you get. Being community driven and trying to be as stable as possible comes with the drawback that you're not fast. If you're more on the bleeding edge side of life, raspian nor debian stable is the way to go.. your best friends are more likely distros like arch, fedora or debian sid and the make command..

[pica200]

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.

You never needed it but i ran into a few cases where it proved very useful. You can implement a very fast integer log2 with it which is useful for bitmaps or hardware registers. That's probably the difference. We see it from different perspectives. You from the userland software perspective and i from the bare metal/driver perspective.

likely for 99% of all debian packaged it doesn't matter if you get them from the Raspian repo or the debian repo in terms of which version you get. Being community driven and trying to be as stable as possible comes with the drawback that you're not fast. If you're more on the bleeding edge side of life, raspian nor debian stable is the way to go.. your best friends are more likely distros like arch, fedora or debian sid and the make command..

Yes, this is why i mainly use Manjaro which is based on Arch. As long as i can fix the bugs with simple instructions i'm not too bothered. If i need something that just works reliably Debian and Co. are the right choice.

[dickon]

You never needed it but i ran into a few cases where it proved very useful. You can implement a very fast integer log2 with it which is useful for bitmaps or hardware registers. That's probably the difference. We see it from different perspectives. You from the userland software perspective and i from the bare metal/driver perspective.

Clearly ARM felt that the instruction was required, which is why they added it. It's just something I've never needed to do, unlike, say, an integer division, which is why it surprised me. It just seems a bit niche.

[rpdom]

Clearly ARM felt that the instruction was required, which is why they added it. It's just something I've never needed to do, unlike, say, an integer division, which is why it surprised me.

The first ARM chip didn't even have integer multiplication. That was added in the second version.

[dickon]

Clearly ARM felt that the instruction was required, which is why they added it. It's just something I've never needed to do, unlike, say, an integer division, which is why it surprised me.

The first ARM chip didn't even have integer multiplication. That was added in the second version.

I'm well aware of that...

[DougieLawson]

Clearly ARM felt that the instruction was required, which is why they added it. It's just something I've never needed to do, unlike, say, an integer division, which is why it surprised me.

The first ARM chip didn't even have integer multiplication. That was added in the second version.

You don't need a multiply. Integer multiplication is an integer numbered series of additions.

[rpdom]

Clearly ARM felt that the instruction was required, which is why they added it. It's just something I've never needed to do, unlike, say, an integer division, which is why it surprised me.

The first ARM chip didn't even have integer multiplication. That was added in the second version.

You don't need a multiply. Integer multiplication is an integer numbered series of additions.

Yes, I'm well aware of that. But using one instruction that takes up one (or a very small number of clock cycles) is a lot faster than coding your own. Which is why the ARM2 had a MUL instruction.

Division on the other hand was a lot more complex to implement.

[Heater]

You don't need a multiply. Integer multiplication is an integer numbered series of additions.

What is your point there?

We don't need addition either. Addition is just a bunch of logic that can be done with AND, OR, XOR and the like.

Depends how slowly you want things to run I guess.

[DougieLawson]

We don't need addition either. Addition is just a bunch of logic that can be done with AND, OR, XOR and the like.

Pah, you don't need AND, OR or XOR. You can build those from a NOR gate.

[Heater]

That is true, or only NAND gates if you like of course.

People are often heard speaking of the "bloat" of Intel processors thanks to it's instruction set.

Thing is Intel CPU's do not execute that instruction set directly, rather they decode it into a mass of much simpler RISC like operations.

Given the enormous caches and bazillions of transistors used on pipe lining, parallel execution units, instruction re-ordering, branch prediction, etc, etc, the actual percentage of transistors used to do that instruction translation is only a small part of the whole.

As such, I strongly suspect the the instruction set itself does not cause much in the way of bloat in the chip resources.

Still, I agree, the X86 ISA is nuts. Or "a dog" as one ex Intel guy who was responsible for marketing x86 back in the day finally admitted in a recent Computer History Museum video.

[jahboater]

Thing is Intel CPU's do not execute that instruction set directly, rather they decode it into a mass of much simpler RISC like operations.

Or remove the instruction completely if the result is obvious.

I think the decoders are getting very very complicated nowadays.