From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: "Significant Garbage Collection Improvement For Emacs" - sweep_conses performance improved by 50%? Date: Sat, 29 Oct 2022 10:32:39 -0400 Message-ID: References: <871qqr425n.fsf@yahoo.com> <42ba5e8a-8a26-4afd-ab59-efbb967e8a24@app.fastmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8776"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: "Po Lu" , "Stefan Kangas" , "Emacs developers" To: "Tyler Dodge" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 29 16:33:49 2022 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 1oomuC-00024j-1x for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Oct 2022 16:33:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oomtF-0006ut-7A; Sat, 29 Oct 2022 10:32:49 -0400 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 1oomtD-0006ui-LA for emacs-devel@gnu.org; Sat, 29 Oct 2022 10:32:47 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oomtB-0006zI-SP for emacs-devel@gnu.org; Sat, 29 Oct 2022 10:32:47 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8F853100189; Sat, 29 Oct 2022 10:32:43 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E482C1000FF; Sat, 29 Oct 2022 10:32:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667053961; bh=XgfJXTer0RK+ikWv4+2mGQ6aZLXSA/1fyvPTG/YcLdI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pkLwO52eSTG2SBNxYEtutgZ9ZXBvmqplZmyC5xgJXJbOfPzmHzQPK15IelYdRdSp8 NFDFAlEINlClYFO4j8XIUMl710q9v1UONlMFhoOM+pWIwHYfkIeylAIK/Gv4OIsH2k WfqFgiYoOYP9Ew/uZ6NCvg4o0dSWl6j8Xyy+O28K5XP8iImvJO48SMbatKVJ43+GKK NWc9cBdkQsJwIVcFkWY2sbG55IUKNd7KrzsjRrUMzW+SyPYwTERm5CdfZbwqNspk/+ mcSBbeeZtMBgluFGlzSsDe1V6Q2rx4FsHN7vw3dlkZ+JaHaonD//dMPeY7mTNplAWX wnwgg8UGwLq9w== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9A2691209FB; Sat, 29 Oct 2022 10:32:41 -0400 (EDT) In-Reply-To: <42ba5e8a-8a26-4afd-ab59-efbb967e8a24@app.fastmail.com> (Tyler Dodge's message of "Fri, 28 Oct 2022 23:07:56 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298753 Archived-At: Hi Tyler, > I would not be surprised if you are correct in that cache locality has a greater > impact than the branch mispredictions. I'm also not certain that this > would have any effect on other builds than the Mac OS version, so I > would be curious to hear if it does have the same benefit. If the issue is linked to locality or to branch mispredictions, than it should depend on the processor more than the OS. > In my personal setup with the change, the memory usage has not caused > any issues, but I have not measured it that closely. I think this > change would make sense as a configure flag. Basically you're replacing 1kB blocks with 32kB blocks, which indeed seems very reasonable. Back when I introduced those blocks (and their associated bitmaps) I chose 1kB because I wanted something small enough that it couldn't be worse than what we had before, not because it was the best choice. Actually 512B was the smallest meaningful choice, FWIW, because the 8B alignment constraints means that the bitmap eats up at least 8B and an 8B bitmap can accommodate 64 objects, multiplied by the 8B alignment gives 512B. Based on your graph, there doesn't seem to be much need to increase BLOCK_ALIGN past 1<<15, but yes, it would be interesting to find out what's causing the crash when going over that limit. Stefan PS: I liked your hack using a background process to increase the PTY buffer size.