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.
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.
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.
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.
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.
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)
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.
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.
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.
32 vs 64-bit benchmarks:
http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/
Interesting article that clearly demonstrates that 64-bit is not for gamers...
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.
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.
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.
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.
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.
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.
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).
tonestone57 wrote:
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.
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 and others don't believe worth the trouble to push back R1 release to make 64-bit OS.
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.
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.
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.
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!
I've read all the replies on this topic that i created and many of you have quite good opinions. i use 64 bit OSes (win7 and linux) and I do program and use as gaming platform and do normal end users things (web, audiovisual viewing and etc..). I can say that from my relatives experiences they do use more softwares on a 64 bit OS than they used on a 32 bit, specially since the amount of RAM went UP. Most of my family members are Doctors... and most of them use tons of heavy pictures files within the MS office and/or OpenOffice. Surely 64 bit versions of those softwares are quicker than its 32 bit versions.
AFAIK, Beos was created as a truly multimedia purpose operating system (meaning gaming, audio engineering, 3D modeling and what not). Those features are quite interesting and had most fun having with 12x movie running at the same time on haiku and not having "lag" when opening some other softwares...
Now here is a question that might be stupid: Why Haiku has BeOS app compatibility? Is it for testing purpose? Can't we compile those apps with the new gcc 4.x port?
"and most of them use tons of heavy pictures files within the MS office and/or OpenOffice. Surely 64 bit versions of those softwares are quicker than its 32 bit versions."
Yes and no. Microsoft Office is a very complicated application. When you create an MS document Office creates and caches a large number of data structures to support the document, in order to make the whole thing work faster. And yes you can link and embed all sorts of media files, which use other applications for processing. A 100 page Word 2010 document with lots of screen shots, macros, fonts, videos, embedded objects, can use 1 GB. It will use less RAM if you have less RAM but then it will page the disk.
Currently there exists nothing like MS Office on Haiku. Gobe Productive, KOffice, Open Office are possibilities but don't run yet.
Does Haiku really need more than 4 GB RAM when these are available? I would guess eventually but not in the near term. I run Windows 7 64bit with Office 2010 and 4 GB is enough RAM for me right now for my usage patterns.
"Why Haiku has BeOS app compatibility? Is it for testing purpose? Can't we compile those apps with the new gcc 4.x port?"
Do you really want an OS with no applications at all?? You need at least some for testing purposes. Many classic BeOS apps do not have source code available. Also, the core Haiku developers have put their emphasis on the OS, leaving apps for later. So we have mostly classic BeOS apps. We hope this will change as more people discover Haiku and start writing Haiku applications.
"and most of them use tons of heavy pictures files within the MS office and/or OpenOffice. Surely 64 bit versions of those softwares are quicker than its 32 bit versions."
Yes and no. Microsoft Office is a very complicated application. When you create an MS document Office creates and caches a large number of data structures to support the document, in order to make the whole thing work faster. And yes you can link and embed all sorts of media files, which use other applications for processing. A 100 page Word 2010 document with lots of screen shots, macros, fonts, videos, embedded objects, can use 1 GB. It will use less RAM if you have less RAM but then it will page the disk.
Currently there exists nothing like MS Office on Haiku. Gobe Productive, KOffice, Open Office are possibilities but don't run yet.
Does Haiku really need more than 4 GB RAM when these are available? I would guess eventually but not in the near term. I run Windows 7 64bit with Office 2010 and 4 GB is enough RAM for me right now for my usage patterns.
"Why Haiku has BeOS app compatibility? Is it for testing purpose? Can't we compile those apps with the new gcc 4.x port?" Do you really want an OS with no applications at all?? You need at least some for testing purposes. Many classic BeOS apps do not have source code available. Also, the core Haiku developers have put their emphasis on the OS, leaving apps for later. So we have mostly classic BeOS apps. We hope this will change as more people discover Haiku and start writing Haiku applications.
I hate to say this but maybe a WINE port would be worth the effort. it would come at a peformance penalty but it would solve some of the application issues as far as getting people to use the OS.
I am suspicious about how easy it is to port WINE. Haiku is POSIX compliant but has a completely different kernel that Linux. And what window system is WINE coded to? What does WINE expect?
Another issue using WINE is the same issue as using X, QT, KDE, or OpenOffice. These look the same on all platforms. So Haiku loses its identity. Then there iss nothing to differentiate it from Linux. And the main thing that differentiates Haiku from Linux is the user interface.
I think having 3rd party tools are good for options, but not the whole solution.
I am suspicious about how easy it is to port WINE. Haiku is POSIX compliant but has a completely different kernel that Linux. And what window system is WINE coded to? What does WINE expect?
Another issue using WINE is the same issue as using X, QT, KDE, or OpenOffice. These look the same on all platforms. So Haiku loses its identity. Then there iss nothing to differentiate it from Linux. And the main thing that differentiates Haiku from Linux is the user interface.
I think having 3rd party tools are good for options, but not the whole solution.
I don't disagree with your statement about identity. That siad the reason windows has been so sucessful is that they pretty much keep backwards compatability. Newer version are a bit different in this regard but usually a relatviely easy to impement tweaks by application developers get most apps running on WIN anything for the most part.with exceptions of course. The truth is the reason microsoft dominates is becuase of this. A upgrade "aside from vista and win 7 " essentially almost always used to keep apps functioning.win 95 win 98 win 3.1 and win nt and win xp are all fiarly backwards complaint.
that chicken and egg problem. alot of people aren't so tied to a OS as they are applications. If they can't run there apps they have no reason to change. Web browsers aside. Those are fiarly generic and so long as the web works. Most do not care. How many users ever really use a non MS supplied browser anyways on windows ??? its not that big despite the growth of firefox.
supporting windows applications "if haiku aism to be more then a novelty and hobby and developers OS" should be one of those big things that gets done. However that would be best implemented. You can't expect app developers to run to your door unless they have a user base that can generate revenue. So Haiku has to provide them with those solutions or be stuck in the fray. The other isue will be if haiku does gain market presences what will be done about DRM. I could see media production companies targeting Hiaku becuase of the glaring lack of data security in regards to IP and copyrighted music and entertainment works. These folks have alot more money then the entire open source community put together.
BTW I agree moving wine would be massive.
I'd still like to see haiku performance with all of the modern instruction sets in use. I'd bet those performance discrepencys I have tested would pretty much vanish if newer more powerful instructions were used. Its about the only thing x86 has going for it.
Personally I wouldn;t worry abotu differentiating from linux. In fact I wouldn't try to even associate to linux. Linux is aweful and the negative spin on its use as a desktop OS has sealed its fate. BTW its not the appearance of linux. Its the learning curve to use it and the fact that alot of stuff nevers works right that is the huge turnoff.
I would also close the distrobution guidlines to official haiku inc releases only. If this thing does finally luanch to a big audience you don't want 47 bajjillion distros all with wierd problems popping up tarnishing the system. Keep it open source but make it so that all distrobutions are Haiku inc only. All it takes is one bad impression to turn off 1 users who will in effect tell 100 friends.
I personally would be interested in seeing a skeleton outline of requirements needed to port WINE to Haiku. This could be done as an exercise without committing lots of resources.
I would like to point out that Mac OSX is not backward compatible but is also successful :-)
I would state that there are many, many apps that break with each Windows release. Lots of device drivers and games that use performance libs. This is where VMWare, Virtual PC, QEMU come in.
"I'd still like to see haiku performance with all of the modern instruction sets in use. I'd bet those performance discrepencys I have tested would pretty much vanish if newer more powerful instructions were used. Its about the only thing x86 has going for it."
Can you give examples of modern instructions? Is this MMX/SSE?
My big concern is having the right mix of Haiku native applications for people to use, be productive, and be happy. We need an Office productivity package. We need 3D support. We need acclerated video cards. We need some Haiku eye candy applications. We need Teapot 2.0 :-)
I have no idea how big of a job porting WINE would be. One of the biggest obstacles IIRC is that it is designed to run with the Xwindow system. Could cuase some problems there.
Yes but, MacOsX has a backwards compatability mode that is like a virtual machine IIRC.
Yes MMX,SSE 1,2,3,4,5 AVX the 64b stuff etc etc etc. Some of these instructions offer some very powerful features that enhacne performance greatly. Look up the ICC "intel Code compiler" debacle with AMD cpus code path blocks to see how drastic it can be.
I agree on native apps, the big killer isn't 3d or gaming "its a small market in reality" multimedia "which is pretty good right now" is the biggest.
As I see it
Flash "improving gnash" and making it work with webpositive along with better java support and html5 wrap up that area.
aside from some UI stuff the current email client works fine with the exception of the setup being kind of difficult.
Most of the native apps adress the native app issues.BTW most of them are excelent aside from some gui clunkyness that should be relatively easy to adress.
Package management is still a sore spot.
Its the non native stuff, quikbooks,MSoffice, other data systems etc that pose the biggest challenge. The question is whats easier and quicker. Dirty wine port that makes these apps useable of writing new apps that are as capable.
I really don't know the answer to that question.
the only other thing that could be done that would be a tremendous time saver in regards to 3d. Make haiku support windows gaphics drivers. Looking at the state of gallium etc on linux. Windows has the edge in framerate and performance in gaming. the reason is that 995 of the effort of writing a good driver is put into MS product, not linux which is a small user market share.
sorry for the book. sort of 4 topics in one thread.
AndrewZ wrote:
I personally would be interested in seeing a skeleton outline of requirements needed to port WINE to Haiku. This could be done as an exercise without committing lots of resources.
I would like to point out that Mac OSX is not backward compatible but is also successful :-)
I would state that there are many, many apps that break with each Windows release. Lots of device drivers and games that use performance libs. This is where VMWare, Virtual PC, QEMU come in.
"I'd still like to see haiku performance with all of the modern instruction sets in use. I'd bet those performance discrepencys I have tested would pretty much vanish if newer more powerful instructions were used. Its about the only thing x86 has going for it."
Can you give examples of modern instructions? Is this MMX/SSE?
My big concern is having the right mix of Haiku native applications for people to use, be productive, and be happy. We need an Office productivity package. We need 3D support. We need acclerated video cards. We need some Haiku eye candy applications. We need Teapot 2.0 :-)
Comments
Re: 32 vs 64 bit OS
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.
Re: 32 vs 64 bit OS
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.
Re: 32 vs 64 bit OS
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.
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.
Re: 32 vs 64 bit OS
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.
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.
Re: 32 vs 64 bit OS
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 !
Re: 32 vs 64 bit OS
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.
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.
Re: 32 vs 64 bit OS
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-...
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://en.wikipedia.org/wiki/Physical_Address_Extension
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.
Re: 32 vs 64 bit OS
32 vs 64-bit benchmarks:
http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/
Interesting article that clearly demonstrates that 64-bit is not for gamers...
Re: 32 vs 64 bit OS
32 vs 64-bit benchmarks:
http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/
Interesting article that clearly demonstrates that 64-bit is not for gamers...
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 ;)
Re: 32 vs 64 bit OS
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
Re: 32 vs 64 bit OS
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?
;-)
Re: 32 vs 64 bit OS
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.
Re: 32 vs 64 bit OS
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.
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.
Re: 32 vs 64 bit OS
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.
http://en.wikipedia.org/wiki/Phoronix_Test_Suite#Controversies
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.
Re: 32 vs 64 bit OS
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.
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).
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.
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.
Re: 32 vs 64 bit OS
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.
Re: 32 vs 64 bit OS
I and others don't believe worth the trouble to push back R1 release to make 64-bit OS.
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.
Re: 32 vs 64 bit OS
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.
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.
Re: 32 vs 64 bit OS
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.
Re: 32 vs 64 bit OS
I've read all the replies on this topic that i created and many of you have quite good opinions. i use 64 bit OSes (win7 and linux) and I do program and use as gaming platform and do normal end users things (web, audiovisual viewing and etc..). I can say that from my relatives experiences they do use more softwares on a 64 bit OS than they used on a 32 bit, specially since the amount of RAM went UP. Most of my family members are Doctors... and most of them use tons of heavy pictures files within the MS office and/or OpenOffice. Surely 64 bit versions of those softwares are quicker than its 32 bit versions.
AFAIK, Beos was created as a truly multimedia purpose operating system (meaning gaming, audio engineering, 3D modeling and what not). Those features are quite interesting and had most fun having with 12x movie running at the same time on haiku and not having "lag" when opening some other softwares...
Now here is a question that might be stupid: Why Haiku has BeOS app compatibility? Is it for testing purpose? Can't we compile those apps with the new gcc 4.x port?
Re: 32 vs 64 bit OS
"and most of them use tons of heavy pictures files within the MS office and/or OpenOffice. Surely 64 bit versions of those softwares are quicker than its 32 bit versions."
Yes and no. Microsoft Office is a very complicated application. When you create an MS document Office creates and caches a large number of data structures to support the document, in order to make the whole thing work faster. And yes you can link and embed all sorts of media files, which use other applications for processing. A 100 page Word 2010 document with lots of screen shots, macros, fonts, videos, embedded objects, can use 1 GB. It will use less RAM if you have less RAM but then it will page the disk.
Currently there exists nothing like MS Office on Haiku. Gobe Productive, KOffice, Open Office are possibilities but don't run yet.
Does Haiku really need more than 4 GB RAM when these are available? I would guess eventually but not in the near term. I run Windows 7 64bit with Office 2010 and 4 GB is enough RAM for me right now for my usage patterns.
"Why Haiku has BeOS app compatibility? Is it for testing purpose? Can't we compile those apps with the new gcc 4.x port?"
Do you really want an OS with no applications at all?? You need at least some for testing purposes. Many classic BeOS apps do not have source code available. Also, the core Haiku developers have put their emphasis on the OS, leaving apps for later. So we have mostly classic BeOS apps. We hope this will change as more people discover Haiku and start writing Haiku applications.
Re: 32 vs 64 bit OS
Thanks AndrewZ!
Re: 32 vs 64 bit OS
"and most of them use tons of heavy pictures files within the MS office and/or OpenOffice. Surely 64 bit versions of those softwares are quicker than its 32 bit versions."
Yes and no. Microsoft Office is a very complicated application. When you create an MS document Office creates and caches a large number of data structures to support the document, in order to make the whole thing work faster. And yes you can link and embed all sorts of media files, which use other applications for processing. A 100 page Word 2010 document with lots of screen shots, macros, fonts, videos, embedded objects, can use 1 GB. It will use less RAM if you have less RAM but then it will page the disk.
Currently there exists nothing like MS Office on Haiku. Gobe Productive, KOffice, Open Office are possibilities but don't run yet.
Does Haiku really need more than 4 GB RAM when these are available? I would guess eventually but not in the near term. I run Windows 7 64bit with Office 2010 and 4 GB is enough RAM for me right now for my usage patterns.
"Why Haiku has BeOS app compatibility? Is it for testing purpose? Can't we compile those apps with the new gcc 4.x port?"
Do you really want an OS with no applications at all?? You need at least some for testing purposes. Many classic BeOS apps do not have source code available. Also, the core Haiku developers have put their emphasis on the OS, leaving apps for later. So we have mostly classic BeOS apps. We hope this will change as more people discover Haiku and start writing Haiku applications.
I hate to say this but maybe a WINE port would be worth the effort. it would come at a peformance penalty but it would solve some of the application issues as far as getting people to use the OS.
But thats a massive undertaking.
Re: 32 vs 64 bit OS
Which application issues?
I am suspicious about how easy it is to port WINE. Haiku is POSIX compliant but has a completely different kernel that Linux. And what window system is WINE coded to? What does WINE expect?
Another issue using WINE is the same issue as using X, QT, KDE, or OpenOffice. These look the same on all platforms. So Haiku loses its identity. Then there iss nothing to differentiate it from Linux. And the main thing that differentiates Haiku from Linux is the user interface.
I think having 3rd party tools are good for options, but not the whole solution.
Re: 32 vs 64 bit OS
Which application issues?
I am suspicious about how easy it is to port WINE. Haiku is POSIX compliant but has a completely different kernel that Linux. And what window system is WINE coded to? What does WINE expect?
Another issue using WINE is the same issue as using X, QT, KDE, or OpenOffice. These look the same on all platforms. So Haiku loses its identity. Then there iss nothing to differentiate it from Linux. And the main thing that differentiates Haiku from Linux is the user interface.
I think having 3rd party tools are good for options, but not the whole solution.
I don't disagree with your statement about identity. That siad the reason windows has been so sucessful is that they pretty much keep backwards compatability. Newer version are a bit different in this regard but usually a relatviely easy to impement tweaks by application developers get most apps running on WIN anything for the most part.with exceptions of course. The truth is the reason microsoft dominates is becuase of this. A upgrade "aside from vista and win 7 " essentially almost always used to keep apps functioning.win 95 win 98 win 3.1 and win nt and win xp are all fiarly backwards complaint.
that chicken and egg problem. alot of people aren't so tied to a OS as they are applications. If they can't run there apps they have no reason to change. Web browsers aside. Those are fiarly generic and so long as the web works. Most do not care. How many users ever really use a non MS supplied browser anyways on windows ??? its not that big despite the growth of firefox.
supporting windows applications "if haiku aism to be more then a novelty and hobby and developers OS" should be one of those big things that gets done. However that would be best implemented. You can't expect app developers to run to your door unless they have a user base that can generate revenue. So Haiku has to provide them with those solutions or be stuck in the fray. The other isue will be if haiku does gain market presences what will be done about DRM. I could see media production companies targeting Hiaku becuase of the glaring lack of data security in regards to IP and copyrighted music and entertainment works. These folks have alot more money then the entire open source community put together.
BTW I agree moving wine would be massive.
I'd still like to see haiku performance with all of the modern instruction sets in use. I'd bet those performance discrepencys I have tested would pretty much vanish if newer more powerful instructions were used. Its about the only thing x86 has going for it.
Personally I wouldn;t worry abotu differentiating from linux. In fact I wouldn't try to even associate to linux. Linux is aweful and the negative spin on its use as a desktop OS has sealed its fate. BTW its not the appearance of linux. Its the learning curve to use it and the fact that alot of stuff nevers works right that is the huge turnoff.
I would also close the distrobution guidlines to official haiku inc releases only. If this thing does finally luanch to a big audience you don't want 47 bajjillion distros all with wierd problems popping up tarnishing the system. Keep it open source but make it so that all distrobutions are Haiku inc only. All it takes is one bad impression to turn off 1 users who will in effect tell 100 friends.
thats my 0.02
Re: 32 vs 64 bit OS
I personally would be interested in seeing a skeleton outline of requirements needed to port WINE to Haiku. This could be done as an exercise without committing lots of resources.
I would like to point out that Mac OSX is not backward compatible but is also successful :-)
I would state that there are many, many apps that break with each Windows release. Lots of device drivers and games that use performance libs. This is where VMWare, Virtual PC, QEMU come in.
"I'd still like to see haiku performance with all of the modern instruction sets in use. I'd bet those performance discrepencys I have tested would pretty much vanish if newer more powerful instructions were used. Its about the only thing x86 has going for it."
Can you give examples of modern instructions? Is this MMX/SSE?
My big concern is having the right mix of Haiku native applications for people to use, be productive, and be happy. We need an Office productivity package. We need 3D support. We need acclerated video cards. We need some Haiku eye candy applications. We need Teapot 2.0 :-)
Re: 32 vs 64 bit OS
I have no idea how big of a job porting WINE would be. One of the biggest obstacles IIRC is that it is designed to run with the Xwindow system. Could cuase some problems there.
Yes but, MacOsX has a backwards compatability mode that is like a virtual machine IIRC.
Yes MMX,SSE 1,2,3,4,5 AVX the 64b stuff etc etc etc. Some of these instructions offer some very powerful features that enhacne performance greatly. Look up the ICC "intel Code compiler" debacle with AMD cpus code path blocks to see how drastic it can be.
I agree on native apps, the big killer isn't 3d or gaming "its a small market in reality" multimedia "which is pretty good right now" is the biggest.
As I see it
Flash "improving gnash" and making it work with webpositive along with better java support and html5 wrap up that area.
aside from some UI stuff the current email client works fine with the exception of the setup being kind of difficult.
Most of the native apps adress the native app issues.BTW most of them are excelent aside from some gui clunkyness that should be relatively easy to adress.
Package management is still a sore spot.
Its the non native stuff, quikbooks,MSoffice, other data systems etc that pose the biggest challenge. The question is whats easier and quicker. Dirty wine port that makes these apps useable of writing new apps that are as capable.
I really don't know the answer to that question.
the only other thing that could be done that would be a tremendous time saver in regards to 3d. Make haiku support windows gaphics drivers. Looking at the state of gallium etc on linux. Windows has the edge in framerate and performance in gaming. the reason is that 995 of the effort of writing a good driver is put into MS product, not linux which is a small user market share.
sorry for the book. sort of 4 topics in one thread.
I personally would be interested in seeing a skeleton outline of requirements needed to port WINE to Haiku. This could be done as an exercise without committing lots of resources.
I would like to point out that Mac OSX is not backward compatible but is also successful :-)
I would state that there are many, many apps that break with each Windows release. Lots of device drivers and games that use performance libs. This is where VMWare, Virtual PC, QEMU come in.
"I'd still like to see haiku performance with all of the modern instruction sets in use. I'd bet those performance discrepencys I have tested would pretty much vanish if newer more powerful instructions were used. Its about the only thing x86 has going for it."
Can you give examples of modern instructions? Is this MMX/SSE?
My big concern is having the right mix of Haiku native applications for people to use, be productive, and be happy. We need an Office productivity package. We need 3D support. We need acclerated video cards. We need some Haiku eye candy applications. We need Teapot 2.0 :-)