Why moving to 64bit?

[pica200]

Damn it. snes9x-gtk is not even in the repos on Raspian. Not even the cli version. Pretty frustrating so i have to build it myself

On a side note: Never use a Pi 4 with a really old and slow microSD (6.6 MiB/s sequencial!). It's a pain. It was the only one i had left so no choice. The A1 rated cards are totally worth the money.

[gilius2k15]

Damn it. snes9x-gtk is not even in the repos on Raspian. Not even the cli version. Pretty frustrating so i have to build it myself

On a side note: Never use a Pi 4 with a really old and slow microSD (6.6 MiB/s sequencial!). It's a pain. It was the only one i had left so no choice. The A1 rated cards are totally worth the money.

Good old snes9x! Those were the days... super fx emulation, etc. They always had trouble emulating the voices in WeaponLord - but in the end I think even that game now works. We used to follow updates on this site called Emu News Service:
http://webcache.googleusercontent.com/s ... clnk&gl=uk

[ejolson]

Pi4 can technically address 16GB, and I would think a decent 64bit Raspbian will eventually become available for it. No need to wait for the Pi5.

How wide is the data bus between the processor and memory on the Pi 4B?

[Gavinmc42]

How wide is the data bus between the processor and memory on the Pi 4B?

Not wide enough to make a difference
Pretty sure there won't be room for a 64bit data path on the PCB.
There is a link to the DDRAM dta somewhere

[pica200]

Ok, got around to compiling snes9x-gtk. I can reproduce the non-power of two texture issue on Raspian. But i found out it only happens when "Use pixel-buffer objects" is also checked.

snes9x-gtk seems to suffer from some slowdown i'm not seeing on Manjaro. In windowed mode it stutters but reports it's running fullspeed. In fullscreen mode at 50 Hz there is a hiccup in framerate roughly every second which is also not happening on Manjaro. If ihad to guess this is because compositing is turned on on Raspian.

[ejolson]

How wide is the data bus between the processor and memory on the Pi 4B?

Not wide enough to make a difference

At last someone answers this question from 2016. Yet, the answer is somewhat unsatisfying.

Could the memory data bus use exactly 8 wires? If so, would that mean the Pi is morally equivalent to an 8-bit computer?

Sadly, the answer is likely no. The only 16-Gbit LPDDR4 parts in the current Micron catalogue are 32-bit and 64-bit wide.

[Ernst]

How wide is the data bus between the processor and memory on the Pi 4B?

Not wide enough to make a difference

At last someone answers this question from 2016. Yet, the answer is somewhat unsatisfying.

Could the memory data bus use exactly 8 wires? If so, would that mean the Pi is morally equivalent to an 8-bit computer?

With a little bit of searching I found that the one of the Pi4 memory modules marked "D9WHV" is a Micron MT53D1024M32D4DT-053 WT:D with the description: "RAM LPDDR4 32G 1GX32 FBGA QDP" which could indicate a 32-bit wide data bus.

[ejolson]

Not wide enough to make a difference

At last someone answers this question from 2016. Yet, the answer is somewhat unsatisfying.

Could the memory data bus use exactly 8 wires? If so, would that mean the Pi is morally equivalent to an 8-bit computer?

With a little bit of searching I found that the one of the Pi4 memory modules marked "D9WHV" is a Micron MT53D1024M32D4DT-053 WT:D with the description: "RAM LPDDR4 32G 1GX32 FBGA QDP" which could indicate a 32-bit wide data bus.

As suspected. All hopes that the Pi 4B is morally equivalent to the 8-bit machines from the golden age of personal computing have been dashed. It's more like the original IBM PC where the native register size is twice the data-bus width.

The fact that reading a 64-bit register from RAM apparently requires two 32-bit memory cycles to complete may help explain why Raspbian runs in 32-bit mode. This is also likely the reason why Python, in general, runs 10 to 20 percent slower with a full 64-bit operating system.

More information comparing Python running on the Pi 4B in 32-bit mode to native 64-bit may be found in this post.

[pica200]

That's disappointing but expected. The Pi 4 looks good at first but if you dig deeper you find more and more compromises. Having a 64 bits bus would have been way better since it already has just 1 RAM chip unlike the competition.

[ejolson]

That's disappointing but expected. The Pi 4 looks good at first but if you dig deeper you find more and more compromises. Having a 64 bits bus would have been way better since it already has just 1 RAM chip unlike the competition.

In my opinion a 32-bit data-bus for memory is good engineering. Using two chips or a 64-bit bus would result in a more crowded design, routing difficulties and likely a circuit board with more layers. Over time the cost of higher density memory is likely to decrease while the cost of manufacturing a circuit board with more layers not.

Although the gimmick of dual HDMI outputs gives the current Pi a noticeable feature advantage over every competitor, the quad Cortex A72 processor is also quite solid. If I were dreaming about the next surprise useful for reliable IOT, robotics, physical computing and edge applications, it would not be a 64-bit data bus, but ECC memory.

[pica200]

The L2 cache is not very big either so memory bandwidth makes a difference. 32 bit bus per chip may be fine if you have 2 of them but for 1 it makes more sense to go 64 bit. This gives 64 bit distros an unfair disadvantage.

And the 2 micro HDMI ports are a gimmick as you said. If you go dual display but at low cost then might aswell choose mini DisplayPort which is more durable, license free, can do everything HDMI can except HDCP (which no Pi user will ever want/need) and is even included in USB 3.1 and up (type C). Someone was bringing up some of these points aswell but i forgot where and the first answers were how DP can't do audio which is nonsense. And another advantage is many notebooks/laptops have miniDP like mine and i have an adapter to HDMI already so i could have used that instead of buying a new cable.
The only reason HDMI is pushed so much and is so widespread is because of scummy DRM crap the content industry wants only to be defeated by cheap chinese HDMI splitters so the whole standard is pointless.

[/rant]

[andrum99]

Raspberry Pi don't do gimmicks. The dual HDMI output is there because they have judged that a significant enough proportion of their (potential and current) customer base want dual HDMI monitor support.

Mini DisplayPort is a non-starter as there are far more monitors that support HDMI than DisplayPort, and those that do support DisplayPort also have HDMI.

Also, DisplayPort is not included in USB 3.1 - it is an optional add-on to USB-C.

[Gavinmc42]

Raspberry Pi don't do gimmicks. The dual HDMI output is there because they have judged that a significant enough proportion of their (potential and current) customer base want dual HDMI monitor support.

I think they said the education market was still only about 10% of sales and the Digital signage market was bigger.
Digital signage is probably going to be HDMI TV based not Display port monitors due to the cost of the displays?
Now with 4K TV' prices dropping that needed addressing too.
There are more 4K TV's than 4K monitors being made, volume determines the pricing.

DDRAM data path width would need two of those 32GBb chips.
Not sure how to make a PCB with that amount of data, buried laser vias , 12 layers?
Compare the single Pi4 DDR to PC DDR DIMM modules of a few years ago, 8-16 chips on those for 4GB.

Fetching a 64bit variable from memory will take longer on a 32bit bus.
But that bus is faster than the older Pi3B DDR2.
To go faster, go back to the original stacked SoC, DDR on the CPU die?
This reduces the data path links and PCB routing hassle.
Just a little problem of the heat then.

I think we go a pretty good solution especially for the price
It's not perfect but compromises were few.
The latest technology would be very expensive and redundant in a few years anyway.

[pica200]

Mini DisplayPort is a non-starter as there are far more monitors that support HDMI than DisplayPort, and those that do support DisplayPort also have HDMI.

Ok let's see. How likely is it to have a micro HDMI --> HDMI adapter or cable? Very unlikely because rare/obscure connector.
And how likely is it to have a miniDP --> HDMI adapter? Much more likely since miniDP is widespread in laptops and most monitors or TVs have HDMI (gaming monitors are actually starting to support either DP or DP over USB C and graphics cards have supported DP since years now because they know DP is just better).

See what i mean? You need adapters or cables anyway no matter if micro HDMI or mini DP and it's much more likely you will have one for the later already. I have seen people destroy micro HDMI ports on their Pi 4 already because it's just flimsy and broken by design.

[andrum99]

Ok let's see. How likely is it to have a micro HDMI --> HDMI adapter or cable? Very unlikely because rare/obscure connector.

That's not the issue. The issue is whether the monitor supports DisplayPort. Micro-HDMI to HDMI is a much simpler conversion than mini-DisplayPort to HDMI. You also need a GPU that supports DisplayPort. Do Broadcom even have such an IP block?

And how likely is it to have a miniDP --> HDMI adapter? Much more likely since miniDP is widespread in laptops ...

Mini-DisplayPort is certainly not widespread in laptops. HDMI is still much more common, probably because most monitors have HDMI - far fewer have DisplayPort.

[ejolson]

Ok let's see. How likely is it to have a micro HDMI --> HDMI adapter or cable? Very unlikely because rare/obscure connector.

That's not the issue. The issue is whether the monitor supports DisplayPort. Micro-HDMI to HDMI is a much simpler conversion than mini-DisplayPort to HDMI. You also need a GPU that supports DisplayPort. Do Broadcom even have such an IP block?

And how likely is it to have a miniDP --> HDMI adapter? Much more likely since miniDP is widespread in laptops ...

Mini-DisplayPort is certainly not widespread in laptops. HDMI is still much more common, probably because most monitors have HDMI - far fewer have DisplayPort.

While the High-Definition Multimedia Interface versus Display Port discussion is interesting, I'm not sure the difference is important when moving to 64-bit.

From my point of view, the performance loss with Python is a pretty clear reason to stick with 32-bit. However, if the kernel can be updated to 64-bit while keeping Python and most of the other system utilities 32-bit, that would open the door to running where there is an advantage a few select binaries, such as web browsers and of course sysbench, in 64-bit mode.

[pica200]

Is the Python comparison even a fair one? The difference seems too high to be true. Any AArch32/64 specific code in the interpreter? Hand optimized assembly?

[Heater]

Yes it's fair. I have run that code on a 64 bit Pi running Debian, in the form of Pi64.

I have also notice some programs in Rust, a compiled language, getting slower on 64 bit Pi.

It's all very odd.

One could speculate that with all the ints and pointers being twice the size pressure on the cache is causing the slow down when handling large data sets. I have no idea really.

[jdonald]

Any AArch32/64 specific code in the interpreter? Hand optimized assembly?

Yesterday I did a cursory search for such cases of hand-optimized assembly and that does not appear to be the case. pyaes is a pure-Python AES implementation (does not rely on OpenSSL, which otherwise would have brought the bugs analyzed earlier this thread), and in general Python module writers don't seem to be interested in optimizing for armhf outside of TensorFlow.

I came up with an alternate explanation that needs to be validated. See the Liberation thread that ejolson linked and please comment.

Heater, your Rust tests were ARMv6 baselined and thus invalid. Please see my posts above and rerun your tests.

Edit: Actually I remember now. It was my first Rust test that accidentally targeted ARMv6. My main concern about the earlier Rust tests though is that they are across different distros and thus not apples-to-apples.

[ejolson]

Is the Python comparison even a fair one? The difference seems too high to be true. Any AArch32/64 specific code in the interpreter? Hand optimized assembly?

The comparison is not fair: As mentioned above, the 32-bit Python on Raspbian is compiled to be reverse compatible with the ARMv6 architecture of the original Pi and Zero computers. In particular, by optimizing for ARMv7 the speed of the 32-bit baseline increases by another 10 to 20 percent, which makes the 64-bit results look even worse.

I've heard when compiled for 64-bit architectures that Python uses 64-bit integers internally for everything including characters. The Pi is a bit unique, apparently, in being a 64-bit processor tied to memory by a 32-bit data bus. For comparison, the width of a standard DDR4 SIMM is 64-bits and many PCs are dual or quad channel.

While there are likely quite a few ways to make a 64-bit version of Python that runs faster on the Raspberry Pi, anyone actually doing do and the patches being accepted upstream would be a miracle the size and scope of which could bring millions of Raspberry pythonistas to a true 64-bit conversion.

[pica200]

Using 64 bit integers for everything is really stupid. What did the Python devs smoke when they made this decision? That explains the slowdown for sure and why everything else sees much better results.

[Heater]

Does it make much difference, Python is so slow anyway. If you are concerned about climate change and global warming you should not be using Python

[andrum99]

From my point of view, the performance loss with Python is a pretty clear reason to stick with 32-bit. However, if the kernel can be updated to 64-bit while keeping Python and most of the other system utilities 32-bit, that would open the door to running where there is an advantage a few select binaries, such as web browsers and of course sysbench, in 64-bit mode.

It's not clear to me what the current state of support for running 32-bit binaries on 64-bit Linux actually is. Ideally you would be able to run pretty much anything you wanted that ran on 32-bit Raspbian on 64-bit Raspbian (which are of course ARM), but from what I can gather even on x86/x64 this can be problematic. It's a curious design feature on the Pi 4 that they have apparently gone for a 32-bit data bus for the memory interface. I have a feeling that we may need to wait until Pi 5 for faster 64-bit on a Pi. That's not a complaint by the way!

I suspect the best way to have good 32-bit support on a 64-bit distro would be to have a dedicated 32-bit chroot environment. That would also be a cleaner implementation, since all of the "compatibility" stuff would be in one place.

[pica200]

lol yeah, not using Python myself because it's really annoying having the interpreter as dependency for every script (not as much a problem under Linux as under other operating systems because almost always pre-installed) and it's slow indeed. The only thing i think it's good for is making prototypes of whatever code you want to write in a lower level language or writing a quick script to convert or parse some file.

But the 64 bit integer for everything thing... i can't stop facepalming.

[Paeryn]

I've heard when compiled for 64-bit architectures that Python uses 64-bit integers internally for everything including characters. The Pi is a bit unique, apparently, in being a 64-bit processor tied to memory by a 32-bit memory. For comparison, the width of a standard DDR4 SIMM is 64-bits and many PCs are dual or quad channel.

While there are likely quite a few ways to make a 64-bit version of Python that runs faster on the Raspberry Pi, anyone actually doing do and the patches being accepted upstream would be a miracle the size and scope of which could bring millions of Raspberry pythonistas to a true 64-bit conversion.

I'm not sure that Python uses 64-bit integers for everything. Python only has one integer type integer which is an arbitrary precision integer. The representation that CPython uses is PyLong which divides the integer into an array of 30-bit integers (yes 30, not 32) and if more than one word is needed then the absolute value is stored (the sign is encoded in the length of the integer).

The code for adding two integers first checks if they are both a single word (30-bit word in a 32-bit memory location), if so it just adds the two registers. If either one of the integers is two or more words (so 31-bit upwards) the the addition is done by adding each pair of 30-bit elements. There doesn't look to be any code that would do it in a single 64-bit register.

So my take on it is that 64-bit Python is slower is due to extra memory traffic and that it isn't making use of native 64-bit integers where it could.