Can binaries be compiled for armhf under 64bit Raspberry Pi OS? Under Ubuntu, this is possible and in my RAM intensive applications armhf will beat aarch64. This is similar to x32 ABI vs. 64bit on Intel/AMD.
Announcement
Collapse
No announcement yet.
Raspberry Pi OS 32-bit vs. 64-bit Performance
Collapse
X
-
Originally posted by tildearrow View PostDid the Pi just outperform my Phenom server by a factor of 5 in the LAME test?
Wow! Now it's only half the speed of my 6700K!!!
"only half the speed of my 6700K"
this is in fact impressive for such a device...Phantom circuit Sequence Reducer Dyslexia
- Likes 1
Comment
-
Originally posted by discordian View PostAnd arm7 still had integer divisions optional, even if the hardware was available almost everywhere. Heck, even their cortex-m microprocessors have this mandatory.
Linux and most software will bake in function calls instead of a single instruction for that reason, unless you set march to a CPU with int-div. (To add insult to injury, there's no GCC flag to just enable it)
Trapping the instruction would offset the cost towards the presumably more rare division-less processors. It would be crazy to run a heavyweight OS like Linux on a processor without integer division anyway...
Edit: Actually trapping instructions is a great way to make CPUs instruction sets more flexible. E.g. x86 is full of obsolete instructions, which could be trapped and emulated on modern processors to save some silicon.Last edited by Veto; 07 February 2022, 05:38 PM.
- Likes 1
Comment
-
Originally posted by Veto View PostJust curious, but why function call the instruction instead of just trapping it? I thought interrupts are somewhat cheap on ARM?
Originally posted by Veto View PostTrapping the instruction would offset the cost towards the presumably more rare division-less processors. It would be crazy to run a heavyweight OS like Linux on a processor without integer division anyway...
What linux does is "live-patching" early - overwriting the call to the div function with the instruction if hardware is available. But during compiling it still has to be assumed that a function call takes place, stack might need to setup, registers are considered clobbered, suboptimal code in other words.
Originally posted by Veto View PostEdit: Actually trapping instructions is a great way to make CPUs instruction sets more flexible. E.g. x86 is full of obsolete instructions, which could be trapped and emulated on modern processors to save some silicon.
MIPS/RiscV is nice as there are no separate instruction sets, 32bit is just a subset of instructions. Not 2 (or 3 with Thumb2) instructionsets and decoders like ARM has to do.
- Likes 2
Comment
-
Originally posted by atomsymbol
Given the particular set of benchmarks in this Phoronix article: The performance difference isn't caused by the ISA being 64-bit and not being 32-bit - but caused by the fact that the 64-bit AArch64 ISA happens to be a redesigned ISA. If AArch64 was ported to 32 bits then, obviously, the port would outperform AArch64 on a Raspberry Pi 4GB.
Performance advantage of 64-bit integers over 32-bit integers can indeed be demonstrated, but only using a different set of benchmarks than the set used in this Phoronix article.
Your mind fails to understand the core idea behind the argument "You don't usually need 64 bits - thus 32 bits is faster".- Double the operand size
- Better designed ISA
- Double the registers
- Improved calling convention
- Newer instructions
There was one benchmark that improved to 5x of the original code. I don't think a person could look at that and conclude that the only difference was because of a doubled operand size--there had to be other factors at play.
Certainly, one could take the time to run some other testing and determine what of the listed factors impacted each benchmark, but that's well outside of the scope of this article. The question it sought to answer was "For iso hardware, what difference in performance is there between the 32 bit and 64 bit Raspbian OS for self compiled code?"
- Likes 7
Comment
-
Originally posted by discordian View Postyou thought wrong, its only kinda true on the microprocessor line (Cortex-M). And even then, you would then have to read, decode and emulate the binary code of teh instruction all while being in a state that's not or really complicated to interrupt.
Not sure about now, but ~3 years ago I compiled my arm kernels with some patches for that reason.
What linux does is "live-patching" early - overwriting the call to the div function with the instruction if hardware is available. But during compiling it still has to be assumed that a function call takes place, stack might need to setup, registers are considered clobbered, suboptimal code in other words.
Yeah could be, but x86 still has everything down to 16bit on-chip (even if its in some form of microcode).
MIPS/RiscV is nice as there are no separate instruction sets, 32bit is just a subset of instructions. Not 2 (or 3 with Thumb2) instructionsets and decoders like ARM has to do.
There is really no reason why we should waste all that silicon on legacy instructions.
- Likes 1
Comment
-
Originally posted by tuxd3v View PostDo you sure that Raspbian 32bit is armv6?
I was expecting armv7
- Likes 2
Comment
Comment