chwe
Posts: 153
Joined: Tue Jul 31, 2018 1:35 pm

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

Wed Mar 11, 2020 12:59 pm

Heater wrote:
Tue Mar 10, 2020 4:45 pm
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...
jamesh wrote:
Tue Mar 10, 2020 3:40 pm
I'm not arguing that.
I don't only argue against you here.. ;) fyi it came from this one:
rpdom wrote:
Fri Mar 06, 2020 6:41 pm
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.
jamesh wrote:
Tue Mar 10, 2020 3:56 pm
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..
jamesh wrote:
Tue Mar 10, 2020 3:56 pm
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.
dickon wrote:
Tue Mar 10, 2020 3:46 pm
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).
pica200 wrote:
Tue Mar 10, 2020 10:59 pm
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.. :D your best friends are more likely distros like arch, fedora or debian sid and the make command.. :D

pica200
Posts: 216
Joined: Tue Aug 06, 2019 10:27 am

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

Wed Mar 11, 2020 1:53 pm

dickon wrote: 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.
chwe wrote: 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.. :D your best friends are more likely distros like arch, fedora or debian sid and the make command.. :D
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.

User avatar
dickon
Posts: 1458
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

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

Wed Mar 11, 2020 3:55 pm

pica200 wrote:
Wed Mar 11, 2020 1:53 pm
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.

User avatar
rpdom
Posts: 17046
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

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

Wed Mar 11, 2020 4:04 pm

dickon wrote:
Wed Mar 11, 2020 3:55 pm
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.
Unreadable squiggle

User avatar
dickon
Posts: 1458
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

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

Wed Mar 11, 2020 4:11 pm

rpdom wrote:
Wed Mar 11, 2020 4:04 pm
dickon wrote:
Wed Mar 11, 2020 3:55 pm
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...

User avatar
DougieLawson
Posts: 38902
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

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

Wed Mar 11, 2020 4:11 pm

rpdom wrote:
Wed Mar 11, 2020 4:04 pm
dickon wrote:
Wed Mar 11, 2020 3:55 pm
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.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

User avatar
rpdom
Posts: 17046
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

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

Wed Mar 11, 2020 4:26 pm

DougieLawson wrote:
Wed Mar 11, 2020 4:11 pm
rpdom wrote:
Wed Mar 11, 2020 4:04 pm
dickon wrote:
Wed Mar 11, 2020 3:55 pm
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.
Unreadable squiggle

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

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

Wed Mar 11, 2020 4:45 pm

DougieLawson wrote:
Wed Mar 11, 2020 4:11 pm
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.
Memory in C++ is a leaky abstraction .

User avatar
DougieLawson
Posts: 38902
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

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

Wed Mar 11, 2020 5:33 pm

Heater wrote:
Wed Mar 11, 2020 4:45 pm
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.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

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

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

Wed Mar 11, 2020 5:57 pm

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.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5691
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

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

Wed Mar 11, 2020 6:26 pm

Heater wrote:
Wed Mar 11, 2020 5:57 pm
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.
Pi4 8GB running PIOS64

Return to “General discussion”