From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: "Significant Garbage Collection Improvement For Emacs" - sweep_conses performance improved by 50%? Date: Mon, 13 Feb 2023 00:58:20 +0300 Message-ID: <7bd78a657e0d21c2efb81bcdedb9d8bdbb018776.camel@yandex.ru> References: <871qqr425n.fsf@yahoo.com> <42ba5e8a-8a26-4afd-ab59-efbb967e8a24@app.fastmail.com> <874jrsufoa.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7540"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.46.3 Cc: Po Lu , Stefan Kangas , Emacs developers To: Ihor Radchenko , Tyler Dodge Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 12 22:59:11 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRKNL-0001lC-CG for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Feb 2023 22:59:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRKMj-0002Va-S1; Sun, 12 Feb 2023 16:58:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRKMg-0002V6-Ae for emacs-devel@gnu.org; Sun, 12 Feb 2023 16:58:30 -0500 Original-Received: from forward502c.mail.yandex.net ([178.154.239.210]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRKMd-0004Ks-UI for emacs-devel@gnu.org; Sun, 12 Feb 2023 16:58:30 -0500 Original-Received: from sas1-1970a3fc41d8.qloud-c.yandex.net (sas1-1970a3fc41d8.qloud-c.yandex.net [IPv6:2a02:6b8:c08:48a4:0:640:1970:a3fc]) by forward502c.mail.yandex.net (Yandex) with ESMTP id A7DB75E8EB; Mon, 13 Feb 2023 00:58:21 +0300 (MSK) Original-Received: by sas1-1970a3fc41d8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id KwpMh6XY1a61-JTv1LwZo; Mon, 13 Feb 2023 00:58:21 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1676239101; bh=wZCwYtSD4dy1Zzu6lXIQcbRhHguE9cHKk1RmkFx3N6o=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=KjqTL0hBHlIMdik3G+h9xRg1DMwO4kEJ0MFvNq7vgD0pDNg/T4beGmvKangoDy2lq feY7Z4H+35grT1QRZ+Q2q1iIH0EYsL0zVXMYJWYzvlwrPQo7gkoIuTgt1BjONjObuM uVWo23JAUyMuV+mSrsgmcItdbowjoOg9TIXiCBwE= Authentication-Results: sas1-1970a3fc41d8.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: <874jrsufoa.fsf@localhost> Received-SPF: pass client-ip=178.154.239.210; envelope-from=hi-angel@yandex.ru; helo=forward502c.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303203 Archived-At: On Sat, 2023-02-11 at 20:10 +0000, Ihor Radchenko wrote: > "Tyler Dodge" writes: > > > Since writing that blogpost, I did attempt a few variations of adding > > prefetch > > instructions in sweep_conses, but all of the variants I tried ended up > > having > > significantly worse performance characteristics than omitting them. Tha= t > > makes > > it a bit harder for me to believe that it's attributable to cache local= ity, > > but like > > you said, there are a number of other reasons that could be the actual > > cause. > > May I know if there have been any progress on this? > Is there any help/testing needed? > > GC is really making a big impact on Emacs performance. I believe that > many people would appreciate even few percent overall speed-ups if they > can be achieved as easily as described in the post. Even if only on > certain builds. I did some testing of the change on Archlinux, on Intel i5-7200U. First of, I run the (test-garbage-collect-large-cons-allocation) from the p= ost, but I made a small modification to it. As it stands the function takes too = much time and memory for me to wait it out, so I reduced the value `105910837` t= o `10591083`. Running the benchmark three times before and after the change I see reducti= on of `Garbage Collection` time by =E2=89=8825%. Then the question that came up in the thread: by how much memory consumptio= n would increase? I tested `emacs -Q` similarly 3 times before/after, and eac= h time I measured Emacs PSS. I saw no statistically significant difference. Interestingly, while repeating previous test with my packages and config lo= aded (which includes running malloc_trim()), I see inconsistently lower amount o= f PSS with BLOCK_ALIGN=3D15. At first it was significant, but upon further tests = I see it varies. Either way, it does seem to be a bit lower that with the default BLOCK_ALIGN=3D10. So in memory consumption there is either no difference or= even a slight win. So, yeah, nice change. No idea why it's been 3 months and nobody picked it = up =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F Tho now that I looked at it, I may = as well create a patch from it and send for review. Unless there's opposition, I'm planning on doing so tomorrow. Thank you Ihor for pinging (I didn't see this thread) and Stefan for the in= itial posting of the article here!