32 bit vs 64 bit Haiku, Pros/Cons

Besides the obvious backwards binary compatibility loss on 64 bit, what are the current pros and cons of choosing between the two for everyday usage and testing purposes?

32bit more Software at the moment.

But someone is trying to make 32bit Support for 64Bit

1 Like

A video editor uses 8Mb of RAM for each frame of 1920x1080 videos (what you typically capture on your mobile phone). Thats 240 Mb of RAM for 1 second of video. For a video editor with scrubbing to be usable, you’ll only have 6 seconds of video cached on 32 bit systems. On a typical 64 bit system with16Gb system, video editing will be more pleasant.

Next gen video is 4K aka Ultra HD, which is 3840x2160, a 4x increase. Thats 32Mb per frame, or 960 Mb per second. Video editing needs 64 bit systems.

1 Like

No questions, if you don’t need binary compatibility go with 64 bit. It is faster as it can use most of the cpu instruction set (32 bit version assumes anything newer than mmx is optional).


That seems to explain why on my Mac, despite having plenty of free RAM, the 64 bit version runs faster. I can easily see that by running the GLTeapot demo, which gets about 10 or 20% higher frame rates in 64.

I have 6GB, which are correctly reported by the 32 bit Haiku. Does it mean it will be able to address them if I need it, or will there be some problem when I get near the 4GB limit?

As I know 32 bit Haiku can use more than 4GB RAM, but one 32 bit application can use only 2GB.


Do not forget about the targeted CPU, the mesa version and the gcc version, because they are differs, so a direct comparison doesn’t says anything and Teapot is not a benchmark.

I understand there are many variables in place, but is there any general use benchmark tool available in Haiku?

Larger physical/virtual memory usage footprint for computer programs. The 32-bit environment sacrificed OS available memory for extra application available memory within a 4GB RAM maximum environment. As certain software application and business needs continually grew, this became a problem for computer manufacturers in selling their products.

There is no need for 32-bit to go away yet. This is more a business need than a common home user need. Microsoft’s Windows 10 32-bit version is supported until 2025. The main reason most Linux distros dropped 32-bit support was due to resources needed for maintaining packages and fixing the issues on that platform.

NOTE: Windows 95/98/2000/CE/Linux/BSD 32-bit versions are still in use by businesses and academia for specific tasks. Also, consider that the computer gaming community maintain old computers due to their investments in legacy 32-bit games.

Haiku’s 32-bit variant supports legacy BeOS-related applications which either don’t run or not ported to the 64-bit variant (as mentioned). For many applications, the developers or ISVs are no longer available or out of business. Loss of source code and maintenance support for certain legacy software applications and device drivers is why many users and companies continue using 32-bit computers.

1 Like

“general use” not sure what you mean… a web browser benchmark is going to show it as slower.

However in some general desktop use cases likes searching for files it can be much much faster… and more flexible in how you can search than Win/Linux etc…

Wifi drivers are often slower due to not supporting all features of the cards yet… should see improvements there as freebsd improves though.

Libreoffice is probably similar in performance maybe a little slower due to all software rendering.

Thread scheduling is probably pretty ok for any CPU less than 16 cores, it may not be adequate to handle NUMA like on Threadripper (not that it works yet I think, as Ryzen still has issues.)… will be able to test that a little on my KGPE-D16 soon I hope since that will be 32 2.8Ghz AMD piledriver cores. And it’s definitely NUMA.

1 Like

This is most certainly mainly because we use gcc2 for a lot of things in the 32bit version, and it is a lot less efficient in optimizing code. Back when we had non-gcc2 32bit images, the performance difference was already noticeable there.