From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: MPS: weak hash tables Date: Mon, 08 Jul 2024 05:54:27 -0400 Message-ID: References: <-plQctKgNkvp-LJ9ov2QAiXQKxd9V-hI0yz_opRGxQtbknubCjH4rH2-ymgbw_Qr1ZhB1rtlmiEW8XtuIVNr7nR_Yj20AH6WkH6kUGp68g0=@protonmail.com> <_mNcR6ailVKpYHLxgfo_tJlYGeR0AQIzQWluspYYp5_g5pIIKkHLNfFkklQQgOKNiVW8jn8NS3i2dJ7_B2Qyx9v-Dq3MQ9mP8HNL30UWsqY=@protonmail.com> <878qyf4sgm.fsf@gmail.com> <878qye3l81.fsf@gmail.com> <86a5iu4tiy.fsf@gnu.org> <87msmu1uy5.fsf@gmail.com> 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="15764"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , Eli Zaretskii , pipcet@protonmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 08 11:55:22 2024 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 1sQl5e-0003wk-FM for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Jul 2024 11:55:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQl4o-0001rg-EC; Mon, 08 Jul 2024 05:54:30 -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 1sQl4m-0001rR-W3 for emacs-devel@gnu.org; Mon, 08 Jul 2024 05:54:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQl4m-0002Bn-In; Mon, 08 Jul 2024 05:54:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=RjqxulN8DrSd+54xiJFyrFYontgYM4AHZtySANez234=; b=HRag+DNkUyAlh1sClH/M NsEH+J6+uAe+KAEVS5ogxsGAkVObfZfo8Y4mh/aL4wJsph77AHyo2JlekKzBhnpS0KJhMw0Yse0BF GTOgMfOPcxQwsFI+RspkqOaAfzC4RsPpe8edLuYaYJ49gVLSUQw1gSVq+iGuxfliyBkPFWgPGeH4f liMSsM1jk+1tHCQ1IXvsoBW3942tV9nut2TWiXzDS3zogpBKSvvj1ZcGZ4nFKJ37YukZMTE9GrVvg AdbL+CGRc7gvImwJ69sgqeZBVwweuOCfrYdGqXcQdv1fLuEpsa4W5LNwWlzXjSx2OyY7AT9C+QOyz SftQpuA1jvsV6g==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sQl4l-0005Tm-P5; Mon, 08 Jul 2024 05:54:27 -0400 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Mon, 08 Jul 2024 11:24:25 +0200") 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:321532 Archived-At: Gerd M=C3=B6llmann writes: > Andrea Corallo writes: > >> Helmut Eller writes: >> >>> On Sat, Jul 06 2024, Gerd M=C3=B6llmann wrote: >>> >>>> Helmut, could you please see if that helps with the pi code? >>> >>> Yes, it helps: >>> >>> ./src/emacs -Q -batch -l \ >>> ~/.emacs.d/elpa/elisp-benchmarks-1.14/elisp-benchmarks.el --eval \ >>> '(elisp-benchmarks-run "pidigits" nil 1)' >>> >>> finishes and requires 41.82 seconds compared to the 12.26 of the non-MPS >>> version. And it uses something like 2.8 GB compared to 350 MB of the >>> non-MPS version (estimated by looking at the RES column in top). >> >> Such a difference in memory footprint is because MPS can't GC at the >> speed the main thread is allocating or for some other reason? > > Yes, that's it basically. The client is allocating at a high rate, > and not much is dying until the end of that phase. What do you mean with "not much is dying"? IIUC the original GC is collecting most of them, so they are not live anymore. > Both together mean > that MPS is scanning like wild to make some room, without having a > chance to find something it can discard. Sounds to me like a bandwidth limitaiton in the collector (we see in this patological case).