“During the coding period, I will first work on the boot loader. I intend to modify the existing x86 boot loader so that it is capable of loading both a 32-bit Haiku kernel and a 64-bit one. Once this is done, I will work on implementing the x86_64 architecture functionality in the kernel. Finally, I will port modules and drivers to the 64-bit kernel. Should I have time, I will also begin work on porting userland.” Heck. Yes.
Its about fracking time!
Especially with all this talk of Haiku being legacy free, 32 bit is indeed a legacy.
Alex, you da man!
Edited 2012-04-30 00:48 UTC
Yes this is indeed great, my favourite Haiku GSOC project this year.
The last time this was a GSOC project it sadly failed, but this guy seems to have alot more experience in the matter and is (judging by the introduction) off to a good start with having already submitted some patches.
Happy about this too considering that other desktop OS like Windows and Macs are going to wall gardens.
Cool stuff, but I don’t understand the extreme excitement of the comment above me and at the end of Thom’s original post. Isn’t Haiku ultra-lightweight anyway? What practical good will a 64-bit port do?
Nevertheless, kudos to Alex! It should be a rewarding project (first year CS student? Wow.) I’m excited, just not on-the-edge-of-my-seat-singing-Hallelujah-and-Hail-Mary thrilled.
I know what you mean. I’m an active Haiku user and have it installed on my hard drive. I suppose the reason I’m not so excited about the 64 bit port is that, after all of the (amazing) work that will be done on it, when I install it, it won’t feel any different than when I was using the 32 bit version.
Compare that to, say, a hypothetical GSoC project to update the GoBe Productive source code for Haiku.
Edited 2012-04-30 01:17 UTC
I’m excited about it because Haiku needs to face forward, not hold on to the past. I realize it is a resurrection of a long-dead OS and needs the backward compatibility for the R1 release, but looking forward I feel it will have much more momentum if there is a 64 bit option.
I also hope this move will push app developers to take the platform seriously, and start porting over the good stuff. I’ve never been an app-paradigm fan, but I have enough common sense to realize that developers in general are focused on apps and that’s where the activity is.
I’m not sure I understand your point. In what way will having a 64-bit version push developers to port their applications?
Like a few people above, I don’t get why people are excited about this.
There are an increasing number of applications where >4GB of RAM are wanted or even needed, especially while multitasking memory hunger applications. For that reason alone a 64-bit port would be welcomed, I’m sure. It would be best, obviously, if the 64-bit version could still run the 32-bit applications (like Windows 7 64-bit can still install/run most 32-bit applications).
Because the computing world in general is moving to 64 bit, just as it did to 32 bit and 16 bit in generations past.
And, as others have mentioned, it makes running Haiku on the most modern hardware much easier. These days even a crappy sub-$200 desktop comes with a multi-core 64 bit processor and 4GB or more of RAM.
The real question isn’t “why are they moving to 64 bit” but “why did it take so long?”
This makes sense. (Not sarcastic.)
Personally I don’t care about binary compatibility anymore. I’d use newly ported Qt stuff along with new native bits anyway, since most of the old software is very outdated.
Haiku is so fast that I doubt you will notice much change in the speed of the operation of the OS.
However, I do have a program that I need to get running to process a 136GB drive image, making such code work in Haiku’s 2GB user space is a pain. I am doing a lot of paging (my own paging system with 16MB pages) that moving to a system with a larger user space will help a lot for example why a 64-bit OS would be handy.
Well there’s the matter of performance, 64-bit code is generally quite a bit faster for cpu-intensive code due to having twice the number of registers and also coming with atleast sse which means all x86-64 binaries can be compiled to take advantage of that.
Alright, 64-bit has more registers, though it is rare to find 64-bit-only software–but I also don’t know enough to know how this works. Do system libraries automatically take advantage of those registers? I’m guessing GCC -march switches do. How much practical difference does this make, however, especially since Haiku is supposedly lightning quick (I haven’t used it personally)?
32-bit has SSE, too, but of course I understand that you mean the subsequent extensions (>= SSSE3). Also, there’s NX.
In sum: point taken, though I’m skeptical that it will make a great practical difference anytime soon. OTOH, the psychological impact it will make is probably worth the effort (see comment above). Not to mention that it’s not my business! I did GSoC once and would’ve hated people weighing the value of my efforts 😉
By simply recompiling the software as 64-bit (assuming it’s compiled rather than assembly code) then the compiler will make use of the extra registers when optimizing and thus generate (generally) faster code.
In short, it doesn’t have to be written directly for 64-bit, although some of the best improvements between 32-bit and 64-bit I’ve seen are with hand written assembly. For instance I recall x264 can do something like ~35% faster encodes when using 64-bit while using more demanding presets.
Depending on what you mean by ‘automatically’, if they are compiled as 64-bit, then yes. You can do this explicitly by adding -m64 to GCC when compiling.
Well os’es are written to be extremely low-latency so optimizations which makes a user-detectable difference are most likely algorithmical rather than the result of compiler optimizations. In short, the OS code will run faster by using these extra registers but you are very unlikely to notice it.
However, when we come to user apps, many of which are not low latency but rely on pure throughput, like compressors, video/audio encoders (like the above mentioned x264), renderers, etc, then the typically ~10-20% improvement in performance with x64 can be a nice boon.
There is one downside to 64bit though, and that is that the code size gets larger (iirc around ~15-20%) which is due to the pointers increasing from 32-bit to 64-bit. This in turn makes 64-bit less efficient performance-wise than it could have been given that the increased code size means it will fill up the cpu caches faster which is also the reason that 32-bit code sometimes (very rarely) can beat equivalent 64-bit code in performance.
There’s a new ABI for Linux (x32) which removes this downside by using 32-bit pointers (and thus smaller code) while still using the extended register set in x64 and has shown benchmarks of being ~15% faster than x64-bit code. However using 32-bit pointers means x32 still suffers from the same 4gb addressable ram limit per process like standard 32-bit code does. However if you are fine with your apps only being able to use 4gb (per process, not systemwide) then x32 should be the best of both worlds as far as performance goes.
32-bit needs to be built with older systems in mind, ie. those without SSE (any version). On an x86-64 computer, the system can assume these extensions are available (and thus use them in the base system and ABI).
This is especially true on Haiku, since it’s compiled for i586, which means but it’ll run on a Pentium Pro, but precludes using SSE2 or later in binaries.
Actually, 586 also includes the original Pentium – Pentium Pro was the first of the 686 instruction set.
It’s important to note that regardless of what x86 arch the compiler targets by default, programs can detect and use any instructions they find at runtime. For example, ffmpeg does this to detect the best encoding/decoding algorithm for each processor it runs on. I remember one such example where a bi-linear scaling mechanism in the app_server was written with several different instruction sets and detected at runtime as well.
This is what cpuid is used for… you detect features, you use what you find, you degrade gracefully with slower fallback mechanisms.
Well, AMD64 is not merely a 64-bit version of x86, but rather a strong improvement over Intel’s design (more registers, no segmentation, etc…), which happens to use 64-bit addressing as a bonus.
Besides, all of the usual benefits of a 64-bit architecture apply, such as the ability to access all of a modern computer’s ram without PAE sorcery, and native implementations of all algorithms which need 64-bit numbers for one reason or another.
Well it’s always a good thing if Haiku will be able to support all of my 8 gigs of memory (or 16 later). Then I can run more memory-hungry software at the same time and open more tabs in web browser.
menuetos is 64-bit but has that made any difference to it’s popularity?
Speaking of which, I just had a look at menuetos website … it’s got USB2 support and DVB-T support in assembly now? Far out. Sorry, get back on topic. Good luck to Alex – nothing wrong with that project.
You mean *its*, NOT *it’s*.
Oh c’mon, man!!!
For many years, Microsoft turned all computers made and shipped for windows, into16 bit slow deamons (This included XP… I could care less to know if anything after that, continued the insanity) All it took, to make most windows systems faster was a simple line of boot code, specifying a 32 bit system. Yes the default was to process as a 386/486. (after the line of code was used, all 16 bit channels that could, became 32 bit, and communication to disks, ram, and within the processor, doubled in band width, so to speak.)
Strange to see that the desire for 64 bit is not comprehended. That would make data channels faster, too… not just the processor (or, that was the case with windows). Also, with ‘more speed’ and ‘more power’… Tim Taylor is happier.
I tried the live-CD of Haiku. Even from CD, it was fast (especially using that as a handicapper).
But, it seems, display drivers (and a few other drivers, etc,) would mean more acceptance… a bit more polish on the GUI, would also help.
I am sure, the systems will be fast, with Haiku. But, unlike ‘Steam Punk’ and its looks, Haiku seems to be a grainy, kludgey display/interface that has no sentimental value.
I was able to work out how things got done, but, I was not impressed with the interface. I use Ubuntu, and am not at all amused by dis-Unity (ergo, I am using 10.04).
I found that BeOS’s grandchild, so to speak, is still amazing in speed… but, it seemed to have been cleaner back then.
This makes no sense. The 386 and 486 were both fully 32-bit processors.
Every x86 processor, including the latest x86_64 bit (unless you have a legacy free machine, but most computers still have a BIOS (or BIOS emulation))
initialise in real mode. The oldest 16 bit mode, in wich they run like the ancient 8086/8088.
I think the speed difference being referred to is related to communicating with the hardware directly in stead of using BIOS calls (which happened in real mode)
The primary difference between Pentiums and newer vs 486 and older was the introduction of Virtual Interrupts. That simplified and sped up the interrupt handling for user mode code, making a significant difference in speed and coding for “enhanced” mode software on the x86. Intel would later work Virtual Ints into certain models of the 486 for people who wished the feature without needing to update the entire computer.
When you see software that runs on a Pentium/586 or better, and not on older hardware, that’s usually the hardware that’s being relied on that prevents it from being used on the older CPUs. Particularly with OSes, which need to handle both user and kernel modes.
There’s nothing wrong with the UI. Think of it like “classic” mode on modern Windows or good ol’ Metacity in Gnome 2 without all the bells and whistles. Personally I don’t mind Haiku UI now, it’s small, cute and pleasing enough for me.
If Haiku-OS wants to remain a media-OS it helps if you can keep all the media files you are working on in memory. 2GB is fine for holding multiple sound tracks but once you want to edit video streams the more memory the better.
My Intel-SSD tops out at 185MB/s on my cheap Haiku-OS and I still notice a response difference between large media files on the SSD vs RAMDISK vs cached in ram.
The more ram the better.
The people who don’t understand the benefits of a 64-bit port shouldn’t be on this site.
Oh wait, I forgot where I was.
16bit is plenty! Get off my lawn! *shakes walker*
Young punks like you should be flogged! 4-bit is MORE than adequate! *shakes bed pan from hospital bed*