Over the past week or two, I’ve been working on refactoring and improving Haiku’s “user_mutex” code, which is the kernel-side component of mutex (locks) for userland applications. While there’s probably still more that can be done in the future, what I have accomplished already makes a significant difference for many applications. GLTeapot’s FPS is about doubled, for example.
I would like to get at least a few more people testing the builds before merging the changes, since this logic is pretty touchy (I think I debugged more than a dozen deadlocks during the experimentation phases of working on this), and while I don’t know of any problems remaining at the moment, it’s possible there’s still some lurking.
You can download a
haiku.hpkg for x86_64 at this link (note that it might expire before too long, I’ll update the link when that happens.)
If you do decide to test, please let me know what happens on your system, for good or bad! Barring any unexpected difficulties, these changes will probably be merged into the nightlies within a few days to a week, hopefully.
WARNING for noobs like me: Do NOT move “haiku.hpkg” to ~/config/packages/.
I did that after updating/rebooting my nightly, and with that package in there, I couldn’t boot anymore on that machine. Trying to use older states from the boot manager didn’t seem to avoid loading “haiku.hpkg”, so I had to boot from a pendrive installation, and move away the package on the HDD.
What worked was dropping haiku.hpkg on
/system/packages/, and waiting for the system to show a dialog asking how to proceed: do not install haiki.hpkg, or do so, but allow uninstall of hrev57083 (and then the _devel one).
Report from “hrev57085_6606_2” from an Atom N450 based netbook.
No detectable changes in performance on either GLTeapot or Chart (DrawBitmap mode). Guess the CPU is too slow and already maxed out? (edit: note… I’ve tested with the intel_extreme driver disabled, otherwise GLTeapot is capped to 60 fps on that machine).
Rest of the system behaves OK so far. Wanna say that drill down menu navigation seems a tad faster, but that might be just some placebo effect
Will report back after trying on my main PC (Phenom II X4).
(A few minutes later…)
No noticeable difference on the Phenom either. Same results that on beta4: GLTeapot around 380-420 FPS, with combined cpu usage fairly fixed at 37%.
Yes, I don’t understand why people insist on using GLTeapot as a benchmark, it’s not meant for that… Normally it will render in sync with the display refresh, there is absolutely no reason to render more often than that.
Maybe this is going to be a noob question, but are these some sort of futex?
Because there are no other built-in benchmarks. GLTeapot should have an option to turn off v-sync.
I created an enhancement ticket for that.
The link has no images to download.
Linked updated again: note “/4” in the URL. This build contains some notable changes from the previous ones, and may make more of a difference (or, if I got something wrong, break more things.) Please do give it a spin, if you’ve tried the previous builds.
What do you mean by “dropping”? I dragged the file to ~/config/packages and got a “Cannot write to read-only volumes”… ??? At what angle do I need to hold my tongue?
The easiest way to install the package is to just use
pkgman. Download it, and then run:
$ pkgman install path/to/downloaded/haiku.hpkg
Awesome - thanks: will give it a whirl.
Anecdotally so far:
- Yes, sub menus seem ever so slightly more snappy
- BePodder appears to sort podcast lists faster
- Youtube video is smoother on core 2 duo in Epiphany (plus pages render faster)
No issues have arisen yet, after 30 minutes of playing…
Sorry, I meant “dropping haiku.hpkg on
/system/packages/” (post edited, just in case). But is better to just use
pkgman install, as waddlesplash suggested
Guess I’ll give “/4” a spin and report here. Tried 6606_3 earlier today, same results as with 6606_2.
No noticeable differences on the Phenom II X4 when running hrev57085_6606_4. CPU still flat-lines at 37% when running GLTeapot give what appears to be the same range of FPS as before.
aaaand. After maybe 20 minutes of playing on 6606_04 in Lagrange and Web (with BePodder open in the background), I got this bomb while mouse-wheel scrolling a Google search result: Crash hosted at ImgBB — ImgBB
That’s an app_server crash. Please type “save-report” at the prompt, and reboot. The report should then be on your desktop. Pastebin it first, it may be a duplicate of another ticket I filed recently.
It seems like this link has expired, as I cannot see any
Which patches should I apply to the source tree?
The Gerrit patch series ending in this one: https://review.haiku-os.org/c/haiku/+/6606/4
Those links are navigable. Going up you see links for other architectures (and the patches and the master taken as baseline) and up again you see it was rebuilt for hrev57086, which has the hpkg now, but given there have been more pushes recently, that one will also be replaced sooner or later.
I updated to 57086 and it happened again, this time browsing in WebPositive (I think it was on a Google search page again…). So maybe it is what you already have logged? Here 'tis - Haiku 57086 Crash - Pastebin.com