64bit vs 32bit benchmark. Eben was right

[ejolson]

I believe if you set _FILE_OFFSET_BITS to 64, all file handling will be 64 bits wide even on 32 bit platforms; it is the default on 64 bits.
http://www.gnu.org/software/libc/manual ... acros.html

In a quick and unscientific comparison - a program on aarch64 was around 10% larger executable size and 10% faster compared to 32 bit ARM.

I'm aware of _FILE_OFFSET_BITS. However, the default integer type is 32 bits on 32-bit platform. Care can be used to get around this to create code that works for both 32-bit and 64-bit architectures. As the majority of software development is done on 64-bit Intel these days, it is possible to find code that used to work on 32-bit and no longer does. Same with little versus big endian and ASCII versus EBCDIC versus UTF8 coding. Updates to code that was carefully designed to work on both no longer does.

Some Linux configurations by default assume the terminal used for the command line understands UTF8. The result is that gcc compiler emits UTF8 encoded diagnostics which become unreadable on older terminals. There is an advantage in keeping up with fashion. Right now the fashion is 64-bit, little endian and UTF8.

[MarkHaysHarris777]

The PI team needs to make Raspbian 64 bit now... and the PI 4B needs to bring more of the GPIO pins to the surface, and leverage 2-4Gb of main memory (and honestly, I'd lean into 4Gb if I were on the engineering team responsible for it).

If not, sooner or later (and probably sooner) the PineA64 board, or another, is going to burry the PI.

edit: PS... and who cares (seriously) if the board is a little more expensive ? ... and nobody cares if its just a bit larger either... just saying.

The RAM limit is due to the GPU, so unless a VC4+ arrives with >1GB support, it ain't gonna happen (the soc is a GPU with a CPU bolted on as a feature).

Obviously, the hardware has to support the ram, or the ram isn't going to work, doh !

... but without 64 bit architecture, greater RAM is not going to happen either ! My point was more of -- if the Raspberry PI Foundation is going to compete in the future it should be thinking of a slightly larger card (more memory - 4Gb) and a SoC that runs significantly cooler (less energy). If the SoC (GPU) is limiting the memory to 1Gb... the SoC needs to go...

... 1Gb isn't enough. And by the by, there was no reason to produce a 64bit SoC if the GPU can't handle more memory ! Again, the issue is not performance in the 64bit instruction set... its all about memory/

[SonOfAMotherlessGoat]

My point was more of -- if the Raspberry PI Foundation is going to compete in the future

But compete with who? This is the Raspberry Pi, an SBC designed and made for education. Designed and made to teach the teachable how to program again. To not rely on 4GB to bloat out things. To foster the kind of engineering creativity that saved 3 human beings with duct tape, plastic bags and LiOH. (1) It's great that there is a memory constraint, forces programmers to think how to keep their designs within a budget. To quote "This is the Unix philosophy: Write programs that do one thing and do it well." 64bits? That was an added bonus.

You want 4GB Ram, EMMC, 64bit? Pine64 is for you! I think the RPF is doing quite well, considering it's nigh impossible to even get one in large sections of the world.

(1) http://sploid.gizmodo.com/this-is-the-a ... 1598385593

[mfa298]

... 1Gb isn't enough. And by the by, there was no reason to produce a 64bit SoC if the GPU can't handle more memory ! Again, the issue is not performance in the 64bit instruction set... its all about memory/

But then I don't think the A53 CPU Core was chosen for it's 64bit capabilities, It was chosen as something that would be a good 32bit upgrade from what was in the Pi2. The potential of being able to run it in 64bit mode in the future is just a bonus.

They could have gone for a (potentially slower) 32 bit only CPU core instead and we wouldn't be having these discussions. Personally I'm glad for the faster CPU cores, it makes the Pi3 potentially good for a range of things.

[ejolson]

. (1) It's great that there is a memory constraint, forces programmers to think how to keep their designs within a budget.

Viewing a 32-bit architecture with a 1GB memory limit as an artistic constraint that encourages programmers to express themselves more clearly is interesting and also opposite to the practicality of simply jumping on the 64-bit bandwagon because that is where most new program development is happening.

My understanding is that a significant amount of the work done by the foundation is funded by the sale of hardware. Successfully manufacturing in the UK further demonstrates a local need for the STEM disciplines. Thus, the future need not be a service economy that relies on banking tricks, intellectual property and tourism to keep afloat. Instead, the economy could be something much greater. For this to happen the Raspberry Pi hardware has to remain competitive with single board computers produced outside the UK.

[SonOfAMotherlessGoat]

And yet the SBC that is almost constantly on the front page of General Discussion, and the cause of many a thread is a 32Bit Single Core 1GHz card with1 Gig of RAM sorry 512MB RAM, 1 USB port, no onboard networking and retails for $5USD. I know the RPF doesn't release numbers, but I think they are doing pretty well?

[asandford]

Obviously, the hardware has to support the ram, or the ram isn't going to work, doh !

... 1Gb isn't enough. And by the by, there was no reason to produce a 64bit SoC if the GPU can't handle more memory ! Again, the issue is not performance in the 64bit instruction set... its all about memory/

The GPU is the same 'bitness'' in all Pi variants, only the CPU changes across the range (the vast majority of the soc is the GPU).

The point I was making (which you missed) was that there is no videocore hardware to support the ram, and to upgrade the VC IV to do so would probably be many millions (of whatever currency happens to be worth anything at the moment). To gain more memory means abandonig the current soc (and all the work that has been done on it) ang going for something else (VCexit?).

[W. H. Heydt]

As an aside... I keep looking at the thread title and imagining the Jaegermonsters in "Girl Genius" describing Eben as a "schmot guy". while exposing big, very toothy, grins.

[jamesh]

. (1) It's great that there is a memory constraint, forces programmers to think how to keep their designs within a budget.

Viewing a 32-bit architecture with a 1GB memory limit as an artistic constraint that encourages programmers to express themselves more clearly is interesting and also opposite to the practicality of simply jumping on the 64-bit bandwagon because that is where most new program development is happening.

I don't agree with this. Embedded systems, which make up a huge percentage of software projects, are almost all 32bit, limited memory systems. Learning to write code that works in those environments is only becoming more useful, not less. For most SW projects, the 32 or 64 choice is irrelevant, just write the code.

My understanding is that a significant amount of the work done by the foundation is funded by the sale of hardware. Successfully manufacturing in the UK further demonstrates a local need for the STEM disciplines. Thus, the future need not be a service economy that relies on banking tricks, intellectual property and tourism to keep afloat. Instead, the economy could be something much greater. For this to happen the Raspberry Pi hardware has to remain competitive with single board computers produced outside the UK.

Every thing the Foundation does is funded by HW sales (barring donations from people like Google, but I suspect that has all been spent).

Don't forget competitiveness is not just about price, but the whole ecosystem.

[jamesh]

The PI team needs to make Raspbian 64 bit now... and the PI 4B needs to bring more of the GPIO pins to the surface, and leverage 2-4Gb of main memory (and honestly, I'd lean into 4Gb if I were on the engineering team responsible for it).

If not, sooner or later (and probably sooner) the PineA64 board, or another, is going to burry the PI.

edit: PS... and who cares (seriously) if the board is a little more expensive ? ... and nobody cares if its just a bit larger either... just saying.

The RAM limit is due to the GPU, so unless a VC4+ arrives with >1GB support, it ain't gonna happen (the soc is a GPU with a CPU bolted on as a feature).

Obviously, the hardware has to support the ram, or the ram isn't going to work, doh !

... but without 64 bit architecture, greater RAM is not going to happen either ! My point was more of -- if the Raspberry PI Foundation is going to compete in the future it should be thinking of a slightly larger card (more memory - 4Gb) and a SoC that runs significantly cooler (less energy). If the SoC (GPU) is limiting the memory to 1Gb... the SoC needs to go...

... 1Gb isn't enough. And by the by, there was no reason to produce a 64bit SoC if the GPU can't handle more memory ! Again, the issue is not performance in the 64bit instruction set... its all about memory/

If you want a SoC that uses less power (produces less heat), then you need to go for a less complex one (fewer cores, less speed), or change to a smaller process node.

1GB is enough btw. Write better code.

The A53's on the Pi3 run 32bit code faster than the 32bit cores. That's why they are better. The NEON extensions are better and there are more registers - AIUI, even in 32bit mode. The a53 is a better 32bit core, just ignore (for the moment) the fact it's 64bit.

[kusti8]

+1

I recently wrote a program that basically does audio fingerprinting , consistent FFTs of the audio in real time and analyzing that to find out if a certain song has been played. CPU usage is at 95% on one core and on the other I can run mjpg_streamer at 40%. On a $35 computer, I think this is amazing and having more power isn't useful for the the Pis goal other than saying that we have more power. Write better software and it will run.

[ejolson]

Viewing a 32-bit architecture with a 1GB memory limit as an artistic constraint that encourages programmers to express themselves more clearly is interesting and also opposite to the practicality of simply jumping on the 64-bit bandwagon because that is where most new program development is happening.

I don't agree with this. Embedded systems, which make up a huge percentage of software projects, are almost all 32bit, limited memory systems. Learning to write code that works in those environments is only becoming more useful, not less. For most SW projects, the 32 or 64 choice is irrelevant, just write the code.

The Raspberry Pi distinguishes itself from embedded microcontrollers as a self-hosted development environment that functions as a stand-alone computer. Although most of the software included in Raspbian is developed using 64-bit Intel compatible machines, most of the code is portable and compiles on many different architectures both 32 and 64 bit. At the same time, since 64 bit is the current standard for GNU/Linux systems, the sooner Raspbian follows suit, jumps on the bandwagon and joins the crowd, the easier things will be.

[jamesh]

Viewing a 32-bit architecture with a 1GB memory limit as an artistic constraint that encourages programmers to express themselves more clearly is interesting and also opposite to the practicality of simply jumping on the 64-bit bandwagon because that is where most new program development is happening.

I don't agree with this. Embedded systems, which make up a huge percentage of software projects, are almost all 32bit, limited memory systems. Learning to write code that works in those environments is only becoming more useful, not less. For most SW projects, the 32 or 64 choice is irrelevant, just write the code.

The Raspberry Pi distinguishes itself from embedded microcontrollers as a self-hosted development environment that functions as a stand-alone computer. Although most of the software included in Raspbian is developed using 64-bit Intel compatible machines, most of the code is portable and compiles on many different architectures both 32 and 64 bit. At the same time, since 64 bit is the current standard for GNU/Linux systems, the sooner Raspbian follows suit, jumps on the bandwagon and joins the crowd, the easier things will be.

You said it in your own post - the code is/must be portable between architectures. Therefore is makes no difference whether you use 32 or 64 from a dev point of view. Actually, not strictly true, you should really develop on/assuming 32 bit as the lowest common denominator. The RPF need to ensure backwards compatibility. If they move to wholly 64 bit, the Pi2 and Pi1 suddenly become unsupported.

And many embedded systems use Linux internally, on full brown microprocessors, not microcontrollers. Of course there are still microcontroller embedded systems, but after 30 years writing embedded code, I've never worked on one, it's always been microprocessors. Some 16 bit, but most 32. Never worked on an embedded system with 64bits, it's a waste. 64bit is NOT the standard for GNU/Linux systems. Desktops maybe, but the embedded Linux market is much larger, and mostly 32bit AND limited memory. There is a move to 64bit on mobiles and tablets of course, due to customer 'demand' rather than any real need. I blame Apple for that one.

[ejolson]

64bit is NOT the standard for GNU/Linux systems. Desktops maybe, but the embedded Linux market is much larger, and mostly 32bit AND limited memory.

GNU/Linux refers to the Linux kernel plus GNU packages such as GNU binutils, GNU tar, GNU compiler collection, GNU make, bash and so forth. These are general purpose Unix-like systems that function as desktops and servers. In particular, Raspbian is a GNU/Linux desktop system. While Linux and the basic GNU system tools are likely to be 32-bit capable for a long time, other programs such as web browsers, image and video editors, window managers, databases and office suites already work better on 64-bit.

Many embedded systems are also based on the Linux kernel, however, they do not host Unix-like programming environments built upon the GNU packages. Therefore, I did not include them when claiming that 64-bit is the fashion for GNU/Linux.

16-bit versions of MSDOS were widely used on 386 and 486-class 32-bit hardware. 32-bit software written for IBM System/360 is still run on the 64-bit IBM System z. The 32-bit ARMv6 code for the original Pi also runs on the 64-bit Pi 3. Reverse compatibility is both a convenience and a trap. While 32-bit may be appropriate for full product-line compatibility in Raspbian, it is welcome to see other distributions running in 64-bit mode on the Pi 3.

[jamesh]

64bit is NOT the standard for GNU/Linux systems. Desktops maybe, but the embedded Linux market is much larger, and mostly 32bit AND limited memory.

GNU/Linux refers to the Linux kernel plus GNU packages such as GNU binutils, GNU tar, GNU compiler collection, GNU make, bash and so forth. These are general purpose Unix-like systems that function as desktops and servers. In particular, Raspbian is a GNU/Linux desktop system. While Linux and the basic GNU system tools are likely to be 32-bit capable for a long time, other programs such as web browsers, image and video editors, window managers, databases and office suites already work better on 64-bit.

Many embedded systems are also based on the Linux kernel, however, they do not host Unix-like programming environments built upon the GNU packages. Therefore, I did not include them when claiming that 64-bit is the fashion for GNU/Linux. As you mentioned, the non-GNU Linux system Android has been optimized for 64-bit processors since Lollipop.

16-bit versions of MSDOS were widely used on 386 and 486 class 32-bit hardware. 32-bit software written for IBM System/360 is still run on the 64-bit IBM System z. The 32-bit ARMv6 code for the original Pi also runs on the 64-bit Pi 3. Reverse compatibility is both a convenience and a trap. While 32-bit may be appropriate for full product-line compatibility in Raspbian, it is welcome to see other distributions running in 64-bit mode on the Pi 3.

I'm not sure what point you are making. I am certainly aware of the GNU/Linux distinction. But when you are developing for an embedded system (most of them), you are writing 32bit code, even if you are doing the writing on a 64 bit system. That's my point - if you are writing code to run on Linux, your best bet is write it so that it can compile and work on any future platform. If you deliberately write code that works only on 64bit you are hugely limiting your usage to 32 bit systems, whereas writing it for any depth means it always works. TBH, the difference in code is insignificant.

A huge number of Android devices out here are 32bit - although Android might work faster in 64, it's doesn't mean people are actually using it that way. I've got a brand new tablet from Samsung that uses a 32bit core - it's fine.

Also worth noting that most Linux based embedded systems COULD host development systems based on GNU, if they wanted to. But it's actually easier and faster to run them on a desktop (which can be 32 or 64 bit, it really makes no difference) and cross compile.

[Heater]

What a strange debate this is. 16 vs 32 vs 64 bit. Micro-controller vs microprocessor. Embedded or not....

My take on all this, having started my career in the 8 bit micro-processor and then micro-controller world, is that the lines are well and truly blurred now.

Transistors have become so cheap it often does not matter if you spend extra cents for a 32 bit processor over 16, or now 64 over 32.

I really don't understand the people who say I should be wasting my life writing "tight code" that uses as little RAM as possible. If using RAM gets the job done, and many things can be done faster if you use more RAM, then my boss and his customers are happy. It's far cheaper to optimize my development time than RAM and other hardware usage.

To that end, getting the code completed, as fast as possible, in RAM guzzling, time sapping Javascript or Python is far more sensible than carefully honing a small efficient solution in C/C++.

For sure there are billions of embedded devices running on tiny micro-controllers. If you are involved in developing any of those, sold in huge volumes, then yes you have the motivation to minimize time, space and cost.

[ejolson]

I'm not sure what point you are making.

My point is that Raspbian is a desktop system and desktop applications such as web browsers are quickly becoming too heavy for 32-bit architectures.

It has always surprised me that the Raspberry Pi website doesn't work well with lynx or dillo. These web browsers are based on older standards and run well on 32-bit systems with limited memory. However, a modern web browser primarily developed for 64-bit systems is needed just to access the official website. Rather than updating dillo and the website so they work well together, it is much easier to jump on the 64-bit bandwagon with at least 2GB of RAM.

[jamesh]

Well, 2GB on the current architecture is impossible, so that's a non-starter without going to a different SoC range (which would be as painful as Brexit). Of course 64bit Raspbian is indeed possible, but I don't think it's going to make a lot of difference to web browsers. They are more likely to respond to better HW acceleration than moving to 64bit, so the OpenGL driver will help there (note, the GPU which runs all this acceleration is mostly 32bit!).

It's really a shame that web browsers are so badly written that they 'need' a 64bit architecture and huge amounts of memory. Perhaps it's my background starting with 8bit 32KB systems that make me wonder how on earth programmers can write such inefficient code. I've always been of the opinion that better code is better than better processors. But I suspect I am in a minority.

[Heater]

It's not clear to me that the Pi was intended as a "Desktop system". It's purpose in life is to be a cheap computer for kids to own and learn to hack on.

James, Do we know that browsers are badly written?

It's amazing what a browser is expected to do now a days. What with HTML5, CSS, SVG, Javascript, webgl, video, audio, etc etc. There is pretty much an entire operating system in a web browser. It's no wonder they are so huge, they have to be to support all the standards, no matter how efficiently they are coded.

[ejolson]

It's not clear to me that the Pi was intended as a "Desktop system".

While the Pi hardware, especially the Zero, seems designed for embedded and non-desktop uses, the Raspbian operating system boots directly into a GUI and is clearly intended for desktop use.

[Heater]

The Pi was not originally intended as a embedded system. It was intended as a cheap machine for kids to own, take home and hack on. Cheap enough not to worry if they broke it. To learn to program on, as my generation did with the C64 and such machines. At least that is the way Eben described it back in the day.

The Zero and the CM have a different angle, but that came later.

But now we have to specify what we mean by "Desktop system". Back in the day a "desktop" was Win 3.1 on a machine with a few Meg of RAM, a less than a million pixel screen and a 10MB hard drive.

Or my Atari ST with half a meg of RAM and no hard drive.

Even my first Linux "Desktops" using TWM as a Window manager were pretty meagre in RAM and disk space.

Today a desktop can mean a lot more. A Chrome browser with a dozen tabs open. An Eclipse IDE. Libre Office and a bunch of other stuff all running at the same time fluidly.

Clearly not Pi territory.

[jamesh]

It's not clear to me that the Pi was intended as a "Desktop system". It's purpose in life is to be a cheap computer for kids to own and learn to hack on.

James, Do we know that browsers are badly written?

It's amazing what a browser is expected to do now a days. What with HTML5, CSS, SVG, Javascript, webgl, video, audio, etc etc. There is pretty much an entire operating system in a web browser. It's no wonder they are so huge, they have to be to support all the standards, no matter how efficiently they are coded.

It's implied by their memory requirements.

And the fact that all large pieces of software are badly written to some extent. Linux kernel may be an exception.

[bstrobl]

It's implied by their memory requirements.

And the fact that all large pieces of software are badly written to some extent. Linux kernel may be an exception.

To be fair, I actually blame most website designers for overbloating their pages with Ads, Tracking, fancy animation and other unnecessary toolkits/frameworks. Developers working on web browsers try their best at optimising things like Javascript execution since a slow browser would quickly lose market share.

Also, ask some BSD folks and they will tell you Linux is a badly written piece of garbage

[Heater]

It seems to be a rule that every programmer thinks every other programmers code is garbage.

[bstrobl]

It seems to be a rule that every programmer thinks every other programmers code is garbage.

You don't even need to go that far, my code looks terrible to me 3 months later when a bugfix is required.