Is there a plan for a 64-bit release of Haiku and, if so, is there an expected time in which the 64-bit version might be developed and deployed?
Hi,
the main advantage of 64bit computing seems to be the ability to address very large amounts of memory. I use 64bit linux and even though I have 2 gigs of memory, rarely ever cross 500megs of use. I still thought that 64bit was the way to go. I have since changed my mind. When you have an entire OS idling sub 100 megs, the ability to access 4+ gigs of memory does not seem practical, especially since Haiku is a desktop centric OS. 64bit makes a lot of sense on the server and enterprise but not so much (IMO) in Haiku, at least not yet.
There is a lot to be said about intelligent 32bit design.
That is definitely true, and it is pretty sad how recent versions of Mac OS X, Windows and even Linux distros require multiple gigabytes of memory just for basic desktop use.
Of course even on Haiku having many open browser tabs or windows could start to use up a lot of memory (though for my part I’ll do my best on the new browser to minimize memory usage.) Plus no matter how efficient the OS is, doing complicated audio or video editing (an area Haiku would certainly like to shine eventually) will require a lot of memory. Especially if you get into HD video.
So even if we are OK with 32-bits for now, one day having 64-bit support would be good. But it is definitely less urgent on Haiku than on the other systems where bloat seems to be the norm.
Not only: as many software (codecs particularry) has proven, 64 bit compiles gives 15-25% speedups.
Of course, many other low level optimizations (SSE2/3, for example) would also be great, but are probably more difficoult to achieve than a “simple” compile…
[quote=Reyenweald]Hi,
the main advantage of 64bit computing seems to be the ability to address very large amounts of memory. I use 64bit linux and even though I have 2 gigs of memory, rarely ever cross 500megs of use. I still thought that 64bit was the way to go. I have since changed my mind. When you have an entire OS idling sub 100 megs, the ability to access 4+ gigs of memory does not seem practical, especially since Haiku is a desktop centric OS. 64bit makes a lot of sense on the server and enterprise but not so much (IMO) in Haiku, at least not yet.
There is a lot to be said about intelligent 32bit design.[/quote]
Actually there’s a technical reason why Haiku is limited much more in 32-bit than Windows or a Linux distribution would be if somehow they hadn’t already gone 64-bit. The other operating systems implemented a feature called PAE (Physical Address Extension), a stepping stone toward the x86-64 design in which the hardware page tables were used to access up to 64GiB of physical addresses, although the applications continue to be 32-bit.
This meant 8GiB of RAM was actually useful on a 32-bit Linux. In Haiku, the OS can only recognise about 3GiB of so of physical memory, depending on the chipset in your PC.
But it turns out that this is not even half the trouble. The shortage of virtual addresses remains, and something needed to be done about that too. Haiku uses a technique popular in the early 1990s of splitting the address space neatly down the middle, sometimes called a 2:2 split. This means that everything mapped into an application’s address space is competing for just 2GiB of space, even though Haiku can address more RAM than that.
So when you run a BeOS/ Haiku program, it can’t really use more than 2GiB of RAM. In fact, because of layout issues, it may be significantly less. But not only that, it can’t use more than 2GiB in total for anything. Memory mapped files, for example. It’s often convenient to map an entire file into the address space (you don’t need enough RAM to actually load the whole file), but with Haiku you won’t be
doing this to large files because it can’t cope.
Yes, 64bit brings many additional registers that can be used to increase performance of math-intensive tasks…
Ultimately, the 64bit OSes out there will benefit from these performance enhancements while the 32bit flavors are held back in the x86 stone age 
I was recently logged into my schools 64bit compute server (basically a 8way 64Gb super desktop runnning red hat with fast disks) surprisingly despite all the gobs of ram only 4 Gb was actually being used by applications mainly matlab and other custom multi-threaded code
So what is the rest for… disk cache of cource 
there were about 55Gb or so of disk cache which I imagine greatly speeds up compiling etc… I can compile haiku quite fast on it I assure you I might benchmark it next time noone is using it.
From what I understand, all modern CPU’s have the ability to use more then 4 gig of ram
They say XP 32 could turn the feature on
The reason they don’t, is because at that time, you would need all new drivers
Drivers would need to be written differently, to work above the current 4 gig limit
So Microsoft decided if they will need all new drivers anyway, then they might as well just go 64 bit, and with that, they will need all new drivers, 64 bit drivers
So it makes it easier to understand, IE people wont need 2 kinds of drivers for 32 bit
They will just need 32 bit, OR 64 bit
So, all in all, any OS should be able to turn the feature on, and use more then 4 gig
You just have to do it before there are a million drivers already made
I dont know if any of that is true, or how Haiku could use it. But supposedly, Vista 32 came with the code, but had it turned off, after SP1, they turned it on, and now Vista 32 can use more then 4 gigs of memory
If that is true and correct, then I think Haiku should dig into early, before too many people are using Haiku. memory is getting so chaep, that we will all have more then 4 gig pretty soon now
[quote=tsteve]From what I understand, all modern CPU’s have the ability to use more then 4 gig of ram
They say XP 32 could turn the feature on
The reason they don’t, is because at that time, you would need all new drivers
Drivers would need to be written differently, to work above the current 4 gig limit[/quote]
Yep - it’s called PAE (Physical Address Extension). IIRC, this feature was even available in Windows 2000 (“Advanced Server” anyway) and supported up to 64gb of RAM or something. Drivers were the main problem because they had to understand there was more addressable memory than usual and not crash. The userland could mostly abstract the issue from the individual applications that didn’t know how to deal with it.
That doesn’t mean it’s easy to enable it - as the entire kernel-land must be ready to handle PAE as well.
[quote]So Microsoft decided if they will need all new drivers anyway, then they might as well just go 64 bit, and with that, they will need all new drivers, 64 bit drivers
So it makes it easier to understand, IE people wont need 2 kinds of drivers for 32 bit
They will just need 32 bit, OR 64 bit
So, all in all, any OS should be able to turn the feature on, and use more then 4 gig
You just have to do it before there are a million drivers already made
I dont know if any of that is true, or how Haiku could use it. But supposedly, Vista 32 came with the code, but had it turned off, after SP1, they turned it on, and now Vista 32 can use more then 4 gigs of memory
If that is true and correct, then I think Haiku should dig into early, before too many people are using Haiku. memory is getting so chaep, that we will all have more then 4 gig pretty soon now[/quote]
PAE was an option you could enable in boot.ini for XP (if you were brave) - and probably Vista as well.
I suspect rather than adding PAE support to Haiku’s kernels and drivers, that time could be better spent making the existing code 64bit-clean instead. A compatibility layer can be added to the userland to support running 32bit apps if necessary, but I suspect that’s a waste of effort as well for an OS as young and immature as Haiku.
[quote=tsteve]
I dont know if any of that is true, or how Haiku could use it. But supposedly, Vista 32 came with the code, but had it turned off, after SP1, they turned it on, and now Vista 32 can use more then 4 gigs of memory[/quote]
The Service Pack for Vista just changes the way RAM is reported in hardware reporting. Previously, all versions of Windows reported the memory available to the OS. In Vista SP1, Microsoft decided to report the physical RAM installed.
So changing BOOT.INI or typing in commands you find suggested on the web won’t make it possible to really use 4 GiB of RAM, though you might manage to make your machine stop booting. PAE is enabled in Vista, but a separate setting internally limits the maximum physical address to 4GiB, which in practice means you get much less than 4GiB RAM available to use. PAE is enabled because the new page table layout is needed for the “no execute” bit and other features in modern CPUs.
You are right that the reason for this limit is the poor quality of consumer drivers, in the past Microsoft had a similar problem trying to get vendors to provide drivers that worked on multi-processor machines. Fortunately they mostly got vendors to fall into line on that before multi-core CPUs became popular or there would be a lot of unhappy customers out there.
A lot of the same work has to be done whatever. In a sense x86-64 means PAE is switched on (in terms of CPU status registers this is literally true, enabling the PAE bit is one of the steps in initiating Long Mode on an x86-64 CPU). Of course it does more than that, but the page table changes for example are needed whether you’re building a 32-bit or 64-bit OS.