I’ve been wondering about why is a 64 bit version not available, most computers nowadays are quite capable of running a 64 bit os…
What are your opinion on this matter? Do you think it is worth making a 64 bit?
Haiku will support 64bit sooner or later. There was a SOC (Google summer of code) project this year that aimed to port the kernel to 64bit but sadly it didn’t finish. I believe the initial focus was mainly on Beos compability, which is why there was no hurry to add 64bit support (Beos was 32 bit). In future releases Haiku will most likely drop Beos binary compability with a full switch away from the old gcc 2.x version and at that point I’m certain 64bit support will also become more of a priority. While the added memory range 64bit offers might not be extremely valuable to Haiku right now, for performance the extra cpu registers and of course them being 64bits in size definately makes a difference.
I know that , whilst there isn’t support for 64 bit memory addressing, the kernel does take advantage of at least some of the capabilities of a 64 bit processor, i.e. multiple cores. To be honest, the average user won’t ever need more than 4 gig of RAM anyway.
There are few BeOS/Haiku applications right now that would use more than 4 GB of RAM addressable with the current 32-bit Haiku. In fact, addressing more than 4 GB is mostly to run some of the more advanced games that cache a large amount of data, and server software like databases. the advanced games are commercial and will not be ported to Haiku any time soon. Although Haiku eventually will run server software like MySQL, Apache, JBoss, etc, this is not currently a big priority for Haiku development, which is currently focused on user applications, stability and basic OS features.
With regards to performance from extra CPU registers. I don’t think this will make a noticeable performance difference for most apps that you will run. You would get more performance optimizing applications for SSE and multiple cores, which is something that can happen now.
Once the developers remove the debugging code for R1, Haiku will be faster. Once we get video card drivers supported again, that will make Haiku faster as well, for drawing programs.
Not I wouldn’t like a 64-bit version of Haiku :-). but it’s a matter of first things first.
Multiple cores is not a 64-bit feature. There were 32-bit CPUs with multiple cores (Intel made a line of Xeons like this for example) and there are 64-bit CPUs with a single core.
All the unique features of x86-64 are available only in its long mode, which is 64-bit. This is necessary for compatibility reasons. The other modes (used by Haiku) are compatible with older x86 CPUs.
Some interesting tests on 64 bit FFMpeg and Vorbis encoders have proven to gain interesting speeds:
http://www.forart.it/_audiotest/encoders.png
The above test has been done with the same processor, but different Vorbis encoder builds: it proves that a 64-bit optimized build (the one on the right called “oggenc264”) speed gain is even better than SSE* optimized ones.
(note that “oggenc2LM” is the assembly+SSE manual-optimized encoder)
Hope that inspires !
Well I have to disagree with you, while sse and paralell processing are great performance enhancers where they can be employed, more registers ALWAYS help since they are by far the fastest place to store and retrieve data from. And since the x86 is quite starved on registers, having those 8 extra in 64bit mode can make quite a change in tight loops where you really want to avoid pushing and pop’ing data off stack. Of course it still depends on the app as you said, and Haiku probably doesn’t have alot of applications right now that requires alot of performance (although compiling Haiku would be alot faster using 64bit) but things like compression, video encoding, 3d rendering etc all have a proven track record of benefiting greatly from those extra registers in 64bit mode.
64-bit does not matter much for performance. More to address memory above 3-3.5GB. Usually the cut-off with 32-bit is 3-3.5GB depending on hardware in your computer. On really high end systems could drop to 2.7GB.
32 vs 64-bit benchmarks:
http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/
Percentage calculations, on 4GB results, show mostly 5 to 6% with as high as 10% performance difference.
Haiku now uses PAE. So, OS can address up to 64GB RAM in a computer.
http://dev.haiku-os.org/wiki/R1/Alpha2/ImprovementsSinceRelease
64-bit likely for R2 release because not that important - requires lots of work checking code - would delay R1 release by 6 months or longer.
PS now with PAE, I am close to 4GB RAM whereas before I was at 3GB. This change happened after Alpha2 & will show in current nightly and Alpha3 releases.
[quote=tonestone57]32 vs 64-bit benchmarks:
http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/[/quote]
Interesting article that clearly demonstrates that 64-bit is not for gamers…
[quote=forart.it][quote=tonestone57]32 vs 64-bit benchmarks:
http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/[/quote]
Interesting article that clearly demonstrates that 64-bit is not for gamers…[/quote]
Crysis is notorious for it’s lack of 64bit performance, this has been the case of discussion ever since the demo first came out. Part of it has been blamed on the compiler, as Visual Studio had pretty bad 64bit code generation. But in overall game performance tend to rely on graphics acceleration rather than cpu performance. Benchmarks of interest are cpu intensive applications, again such as archivers, encoders, emulators, compilers. Sadly most online 32 vs 64bit benchmarks are old, and were made when most compilers generated much better code for 32bit than they did for 64bit, but 64bit code generation has since improved greatly. The downside with 64bit is that due to it using 64bit addressing the code will be larger, and in some cases this can have a negative effect on cache utilization. It was quite some time since I benchmarked 32 vs 64bit myself (I only run 64bit now) but I remember that when encoding with x264, 64bit was ~17% faster than encoding the same clips in 32bit mode, Blender showed similar results when rendering but I can’t remember exact percentages. So yes, 64bit does make quite a difference in performance, not for StyledEdit though 
Found a fairly recent (2009-12) comparison between 32 and 64 bit on Linux. As can be seen in many of the cpu heavy tests 64bit has an obvious performance advantage.
http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
To be honest, the average user won’t ever need more than 4 gig of RAM anyway.
You mean, like 640 Kb were supposed to be large enough years ago?
PAE is supported by Haiku since r37233 (June 2010).
This avoid to waste any > 4Gb of RAM installed in the machine and turn them to actual memory, but within the limit of 4Gb continuous addresses.
No application could yet access more than 4Gb, but now up to 64 Gb of RAM is usable within the system by applications, drivers or kernel, all together.
It’s not what’s called a 64bits support, indeed, but at least it mitigate the most annoying cons of being in 32bits these days : those extra RAMs, usefull under others OSes, are not worthless under Haiku anymore. 
For the actual 64bits support, it’s clearly scheduled post R1. Not long after probably, as along breaking old ABI backward compatiblity, switching to 64bits goes often hands to hands. Or it’s easier to do both at same time.
[quote=phoudoin]PAE is supported by Haiku since r37233 (June 2010).
This avoid to waste any > 4Gb of RAM installed in the machine and turn them to actual memory, but within the limit of 4Gb continuous addresses.
No application could yet access more than 4Gb, but now up to 64 Gb of RAM is usable within the system by applications, drivers or kernel, all together.
It’s not what’s called a 64bits support, indeed, but at least it mitigate the most annoying cons of being in 32bits these days : those extra RAMs, usefull under others OSes, are not worthless under Haiku anymore.
For the actual 64bits support, it’s clearly scheduled post R1. Not long after probably, as along breaking old ABI backward compatiblity, switching to 64bits goes often hands to hands. Or it’s easier to do both at same time.[/quote]
This is one of those areas where a Virtual machine like approach "kernel in a kernel" is beneficial. AFAIK thats how the windows compatability modes operate in thoery. Being as the source code is well known such a implmenetation on its surface shouldn't be horrendously difficult. Option B it to allow a seperate kernel to run in a specific core in a partitioned state with its own memory.Ok Rox.
Your benchmark link shows big gains for 64-bit on Linux. Still I would like to see recent benches from Tomshardware or Anandtech since I trust those sites more than Phoronix.
I recall in the past that Phoronix did some benchmark that upset many readers. They had done the configuration or testing incorrect and affected the final results.
In any case, most users will not be affected by going 64-bit. How many use computationally intense programs? You will see majority do email, web, audio+video viewing and office. So, even if you do get a big boost with 64-bit, only those who take advantage of it (low percentage: 5-25%?) will get the real benefit from having it.
Thanks for giving that link so now I see how 64-bit affects Linux. And conclude from it that the performance gains can be really big with certain applications.
[quote=tonestone57]Ok Rox.
Your benchmark link shows big gains for 64-bit on Linux. Still I would like to see recent benches from Tomshardware or Anandtech since I trust those sites more than Phoronix.
I recall in the past that Phoronix did some benchmark that upset many readers. They had done the configuration or testing incorrect and affected the final results.[/quote]
Yes, I am aware that phoronix have a history of inadequate benchmarking. But in this case I speak from experience, I’ve done alot of benchmarking back when I was transitioning from 32bit to 64bit. I do alot of 3d rendering, compression and encoding so this was of great interest to me. Of course you have no reason to trust me (except that I really have no reason to lie as far as I can see it) but hopefully when Haiku supports 64bit you will be able to make your own benchmarks and draw your own conclusions (there really is no substitute for that).
[quote=tonestone57]
In any case, most users will not be affected by going 64-bit. How many use computationally intense programs? You will see majority do email, web, audio+video viewing and office. So, even if you do get a big boost with 64-bit, only those who take advantage of it (low percentage: 5-25%?) will get the real benefit from having it.
Thanks for giving that link so now I see how 64-bit affects Linux. And conclude from it that the performance gains can be really big with certain applications.[/quote]
Yes, it’s true that many of the typical desktop applications won’t see a big (or even noticeable) performance increase from 64bit. But looking at something as general as webbrowsing then certainly it’s an area that can use the extra performance, not only javascript but also all those online videos (flash, webm) will perform better under 64bit. And more and more people are making/encoding their own videos these days, something that also benefits from added 64bit performance, not to mention overall video/audio playback (well, as for audio probably likely only in lossless decoding will 64bit really make a difference). These are things that I feel are ‘general use’ and would all perform better under 64bit.
Sure, these performance increases might not be enough of a draw for someone to migrate from 32bit to 64bit, since unless you are doing stuff that maxes out your computer’s cpu resources there’s certainly a sense of ‘this is fast enough’ that most users feel content to settle with.
I’m not against 64-bit. I and others don’t believe worth the trouble to push back R1 release to make 64-bit OS.
Better to leave 64-bit for post R1, ie: R1.x (x>0) or R2.
This is the agreement among Haiku developers also.
Best to release R1 sooner rather than keep pushing the release date back and back.
It might be interesting in acquiring an approach similare to ReactOS’ latest release (0.3.12 > http://www.reactos.org/it/news_page_61.html):
While the x64 port is still in an early stage regarding the functioning of the kernel, most of the generic compilation issues are resolved and necessary core functionality implemented. These efforts have been merged back into trunk, so that trunk can be compiled for x64 target. With the help of automatic builds, possible breakages can now quickly be detected and resolved. Don’t expect it to boot to GUI though!
Hope that inspires.
[quote=tonestone57]I and others don’t believe worth the trouble to push back R1 release to make 64-bit OS.
[/quote]
Me neither, while the extra performance is nice to have, it’s certainly not mission critical. The devs are the best judges of when 64bit support should be worked on. Too bad the Soc 64bit project didn’t work out, that would have saved the devs some time.
[quote=tonestone57]I’m not against 64-bit. I and others don’t believe worth the trouble to push back R1 release to make 64-bit OS.
Better to leave 64-bit for post R1, ie: R1.x (x>0) or R2.
This is the agreement among Haiku developers also.
Best to release R1 sooner rather than keep pushing the release date back and back.[/quote]
Honestly given the state of BEOS at the time of its demise compared to the state of Haiku. I think R1 is really pretty much here in alot of ways. I have been comparing the 2 and aside from a few things that still don’t work I think its well past due for r1b1. If goalposts are never set progress will never be made. Honestly haiku is already more hardware compatiable then BEOS was. I don’t think I have seen a single beos application that does not run at this point, with the exception of installers.
That and the trac ticket data base needs to be purged. I see alot of old tickets in there which by the looks of things have been fixed long ago.One of the first tasks to is prune the tickets to get a real sense of where the state of the system actually is. In fact it might be a good idea to put them all to the side and restart the ticket data base and see how many reappear. Some are just plain outdated and were fixed long ago.
Just start a new trac database for R1B1 and get this thing into the wild. Its quickly reaching a point of stagnation.