As of hrev53136, we’ve finally replaced the aging
hoard2 with a shiny new mmap-based allocator – mjansson’s
rpmalloc. Thanks to @pulkomandy and @mmlr for helping out with that work!
The main benefit here will be on 64-bit Haiku, as applications will now (finally) be able to use more than 1.5GB of RAM each, a limitation of the old allocator. But there are some pretty nice (10-15%) performance benefits over the old allocator, too
More of the technical details can be found in the commit message, but essentially the only thing to be concerned about is if things start suddenly crashing more often. It’s already known to exacerbate a few pre-existing WebKit crashes (mostly around Google Maps or the like, which were already so unstable as to be unusable anyway.) Please don’t hesitate to give feedback, as always
From rpmalloc’s github… “All entry points assume the passed values are valid, for example passing an invalid pointer to free would most likely result in a segmentation fault. The library does not try to guard against errors.”
I guess that could be considered a feature though… better to outright crash rather than continue doing something wrong… and if it crashes more easily perhaps those bugs will be tracked down sooner.
Very interesting… it seems tracker’s memory use was the most affected perhaps because it allocates and deallocates things more than app_server etc…
I wonder if it would make sense to turn on whole program or at least LTO optimization for some haikuports… that could be a use case that would require more memory during compilation than previously protentially much more. Something sort of like Clear Linux is doing… typically their binaries are decently faster.
Edit: comparing to a build from a week or two ago… It seems to use slighly more memory, hard to say I’ve rebooted a couple times and there was a lot of variance.
Thanks Augustin for the update. The allocator revealed a double free bug I had in a destructor.
I have generally noticed an increase in Haiku performance during the last year. I have an actor model benchmark (thrashing semaphores and thread context switches) which last year would execute in 38s, and today executes in 21s on the same hardware. Still a fair bit away from 9s on OSX and 14s on Linux, but the speed increase is noticeable.
hoard2 (and most other allocators for that matter) behaved the same way. Doing sanity checks on pointers passed to
free is just far too resource intensive, there’s no way to accurately do it without incurring a massive performance penalty. We already have the guarded heap for tracking down memory related bugs anyway.
Allocating large buffers and never freeing them was something that hoard2 already did fine with, so I wouldn’t expect that usecase to be too different here.
Over long uptimes and in applications that have a lot of memory usage fluctuations e.g. WebKit, rpmalloc behaves loads better. In smaller applications, the difference is negligible indeed.
Well, the guarded heap should do that too, as well as a lot of other memory faults rpmalloc won’t catch
Yes, I’ve been doing work here and there on random bits of low-hanging fruit re. performance, so it’s good to hear those optimizations really are stacking up – almost half shaved off already! Probably on a build without
KDEBUG (beta1 qualifies here) it’d do even better, though of course beta1 lacks the last 8 months worth of optimization work, so on beta2, you’ll have to retest again; probably that will be another 10-20% improvement easily
I should spend a few minutes making up a list of all the performance-related commits so far, I guess. The ones related to the locking of the thread hash probably were the biggest impact performance-wise; that was 15-20% even on my 2-core system, and the improvement probably scaled quadratically with core count.
May i suggest to send a notification to rampant pixels guys so they update their readme file in the rpmalloc repository to state that Haiku is also now a supporting plateform?
Both sides will get well deserved extra credits that way.
Well, they are pretty well aware since I @-mentioned them on Twitter about the switch, as well as all the dialogue in PRs and tickets recently…
Does this mean that there might potentially be a decrease in RAM requirements? I’ve mentioned before that I want to try to install Haiku on an old PC laptop with only 256 MB.
(FYI, I don’t want to spend the money at the moment to upgrade the RAM, and I don’t have another PC with a PATA interface to run the installation on.)
If anything it’s probably an increase, especially on Installer, unfortunately. Though last month’s changes to
packagefs caching behavior were a significant decrease, so it’s worth a shot anyway.
Thanks for the replies… I think I’ll try booting the latest nightly installer directly first, and if that doesn’t work, I’ll look into the USB adapter.
Sorry I took so long to respond; there are a lot of times at the moment when I don’t have internet access.