Determining if a binary is 32- or 64-bit?

On Linux (Raspbian), how can you determine whether a binary is 32- or

64-bit? I'm getting told that gpsd segfaults because it's running on a RasPi-1B and it's OK on a RasPi-4B - "because the 4B is 64-bit". I'd like to check the binaries for myself, as I understood all current Raspbian Buster is 32-bit.
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
Loading thread data ...

Use the "file" command, e.g.: $ file /bin/ls /bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux

3.2.0, BuildID[sha1]=67a394390830ea3ab4e83b5811c66fea9784ee69, stripped
Reply to
A. Dumas

Usually the OS is 32-Bit. 64-Bit would slow down the programms by using a lot of space for bytes filled with zero.

Decades ago a worked with a SUN machine with 32-Bit OS and 36-Bit virtual addresses.

Reply to
Jörg W.

I was thinking the opposite. If it were 64 bit it would boost the processing. Why should a program be slower processing on 64 than on 32? Emptiness does not slow down anything or am I wrong?

Reply to
Deloptes

Perfect, thanks! As I expected gpsd 3.20 (for Raspbian) is a 32-bit program, so the talk of 64-bit on the 4B is irrelevant - as I thought it was.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

AFAIK Linux does not support 64-bit applications running on a 32-bit kernel.

Often yes. In both ARM and x86, the 64-bit instruction set has twice as many general-purpose registers as the 32-bit one, improving performance for some code. Anything that deals with quantities larger than 32 bits will also have a performance boost.

Pointers are twice the size, meaning they have higher average memory access costs (more cache misses, lower throughput to RAM). So a very pointer-heavy program might have reduced performance when recompiled for

64 bits.
--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

Memory bandwidth doesn't change but if half the bytes you shuffle between RAM and CPU don't contain useful data then the effective bandwidth is halved. That's that basis of 64 bit slows things down.

However this is ARM and things are not quite that simple because ARMv8 (64 bit) has 32 bit wide instructions and T32 (aka Thumb2) and can often pack code tighter than ARMv7 (32 bit).

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

So in general it means when you execute a 32bit app on 64bit CPU it would execute a bit slower? Then one must assume that the processing power of

32bit and 64bit is exactly the same in this case - correct?

Exactly why I was confused the ARMv8 on the RPi4 has both instruction sets, so for the RPi4 it means there will not be slow down?

Reply to
Deloptes

Correct - this analysis assumes that the only thing changing is the width of the word, which is why this analysis is usually wrong. It is however the basis of most "64 bit must be slower" claims.

Sure the ARM CPUs will run either instruction set. I've not run benchmarks but my understanding is that for most purposes the ARMv8 64 bit code is denser and runs faster than the equivalent ARMv7 32 bit code on the same processor. There are undoubtedly cases where the opposite holds.

This is not a simple question, compiler quality matters too,

If it ever really mattered to me I'd take the time to benchmark the application and OS I intended to use in both modes. I wouldn't expect the results to carry over to any other use case.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

The 64 bit instruction set gives slightly more instructions per cycle, so with small benchmarks which fit in the CPU cache you can see a significant speed increase. However the larger program, the more pressure the larger memory usage it puts on the cache, and will negate the advantages of instruction set, so larger 32 bit programs are quicker.

That's correct, its not just 64 bit pointers in 64 bit mode, but that all instructions are 32 bits long, where as in 32 bit mode the compilers produce a mix of 16 and 32 bit instructions. Eventually the size of the cache on 64 bit processors will increase so the majority of 64 bit code will as fast as the 32 bit equivalent.

I'm running the 64 bit kernel, which doesn't seem to be appreciably slower than the 32 bit one, and the normal 32 bit Raspbian user space, which is the bit that counts. But using raspbian-nspawn-64

formatting link
I can can run 64 bit code in a container and directly compare it against the normal 32 bit stuff.

---druck

Reply to
druck

down.

it

processing

correct?

Surely 64 bit hardware has 64 bit wide buses? So, in *very* simplistic terms, shifting data between regsisters and/or RAM takes the same number of CPU cycles?

Or are there buses narrower than 64 bits creating bottle necks?

--
Cheers 
Dave.
Reply to
Dave Liquorice

There's no such thing as a bus nowadays, but most memory interconnect outside of the CPU is the size of a cache line, which is typically much wider than the size of a machine word (the 32/64 bit quantity we're talking about).

While registers are sized based on the machine word, there are load and store instructions that can transfer multiple machine words per instruction (aarch32 has LD/ST Multiple, aarch64 has LD/ST Pair). It depends on the microarchitecture (in particular the number of ports on the register file), but it doesn't take a lot to do multiple word transfers per cycle.

So the machine word does not directly constrain the sizes of transfers, which are typically microarchitectural rather than architectural limits, although it restricts which operations can be expressed.

Theo

Reply to
Theo

Also in the case of Intel x86 vs AMD64 the code is also often a bit bigger for the 64 bit version of a program which means the processor reads it a little slower and less of it will fit in any memory cache or instruction cache.

I don't know if the same applies to ARM or not.

--
Brian Gregory (in England).
Reply to
Brian Gregory

...than twice the speed of the 32 bit code as it is accessing twice as much memory per cycle.

... and less of it will fit in any memory cache or

..as they are typically twice as big as well. bigger as well...

A little intelligence is a dangerous thing

--
Climate is what you expect but weather is what you get. 
Mark Twain
Reply to
The Natural Philosopher

I've previously been able to play with lots of different architectures (x86, Itanium, PA-Risc, Power, Sparc, MIPS and ARM), and where the both

64 bit and 32 bit code is supported and otherwise there is very little difference in instructions sets, the 32 bit is always marginally faster due to increased code density and reduced cache usage.

The one exception to this is x86, where the 64 bit code is far faster than the 32 bit code, despite decreased code density and increased cache usage. This is because the x86 instruction set is just so bad, its old fashioned CISC style, overly complex, register poor, memory-memory making it very hard for compilers to produce good code. The 64 bit instruction set (amd-64) is an entirely different more modern, with far more registers.

64 bit ARM is quite different 32 bit with twice as many registers but no conditional instructions, but the 32bit wasn't bad to begin with. So their are some gains from the instruction set, which sometimes overcome the disadvantage of code density and cache usage, but sometimes don't.

To muddy the water even further, both amd-64 and ARMv8 have a mode where you can use the 64 bit instruction set, but produce code which only has

32 bit pointers (requires special libraries so not widely used). Which for programs which don't need lots of memory, can keep the advantages of the ISA and lose some of the disadvantage of the cache usage.

Your mileage my vary!

---druck

Reply to
druck

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.