GNOME Bugzilla – Bug 784648
Disable GSlice when building against GNU libc 2.26
Last modified: 2018-05-24 19:40:11 UTC
The 2.26 release of the GNU C library has a new performance optimisation for the system allocator that has a better profile than GSlice, especially when scaling with regards of threads and CPU cores: https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html Given that the performance advantage of GSlice has been decreasing over the years, it may make sense to start disabling the slice allocator by default on selected platforms.
Created attachment 355094 [details] [review] Disable GSlice by default on newer GNU libc versions Starting from version 2.26, GNU libc enabled a new performance optimisation for the system allocator that covers one of the few remaining areas (multi-threaded software) where GSlice has some advantage: https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html Given that the performance advantage of GSlice has slowly decreased over the years, it makes sense to disable GSlice on a set of platforms — starting with glibc.
Review of attachment 355094 [details] [review]: Got some performance comparisons of GSlice vs the new libc? Feedback on the patch: looks OK, but the documentation would need to be updated too.
(In reply to Philip Withnall from comment #2) > Review of attachment 355094 [details] [review] [review]: > > Got some performance comparisons of GSlice vs the new libc? Not yet, though we already had some initial profiles a couple of years ago with system malloc() scaling better/having less overhead on multiple cores than GSlice. I'll try and grab some numbers at GUADEC. The main reason why GSlice is still useful is portability; the system allocator on Windows is still slower than GSlice for repeated small allocations. > Feedback on the patch: looks OK, but the documentation would need to be > updated too. Yes, this was mostly a proof of concept to test the waters.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1278.