From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: weak hash tables Date: Sat, 06 Jul 2024 18:31:02 +0200 Message-ID: References: <86a5iu4tiy.fsf@gnu.org> <87msmu1uy5.fsf@gmail.com> <87cynq1sx0.fsf@gmail.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="12437"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , Eli Zaretskii , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 06 18:32:07 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 1sQ8KU-0002zB-Uh for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jul 2024 18:32:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQ8Jk-0001gT-QP; Sat, 06 Jul 2024 12:31:21 -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 1sQ8Jd-0001cx-EC for emacs-devel@gnu.org; Sat, 06 Jul 2024 12:31:15 -0400 Original-Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQ8JW-0007Fh-MS; Sat, 06 Jul 2024 12:31:11 -0400 Original-Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-426526d31a3so9191045e9.1; Sat, 06 Jul 2024 09:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720283463; x=1720888263; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=VjTTsm4ZZCX1a/ZxnxdWQ2nBvJfoGHEP5PNekVqnJ10=; b=UmEFYP0N7eD4GgsM1cxrc+9TmnNmLcv4Ppk0R0cfPvtbE5QAJ5m/IEF0oQtZNEUeMl faKTM5O5jRhFy4Uao/D6LlEEczaq7st1+SNxSuFiIsfI84Ne21HrD9hwsrSL0t/YbWJX ugdCkHspqNYttqiWpxtulTEW9OAvtv3MSB5YYaAzoizs3TaflWMUJzDX2xQVr4jBrRUk vpXpGV/7QJBmEx0D0znBRa5/OT9JZoXxHfMR/yg4PLxemxxG7jkYRgI5+LV0DbC58Vb4 E82DbfKg0HGo19tUG4tC2qNqyskqt/hB1WRawJ5n+oO0L6VE3yxsYtPc+Dez2xXMLmjX NVOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720283463; x=1720888263; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VjTTsm4ZZCX1a/ZxnxdWQ2nBvJfoGHEP5PNekVqnJ10=; b=LVTm/sdfsXNM9ERgXLp00oWRX8/AaANNhEcqOcjScZI09eQtXyKiIR28M9Db35k1TA 2u+dwyS1nUvBOkHjgzGmHbT2dnn12n/Cs1KzmGGlJgw5uCb1j0GuCtQD2K0mRAEZSRMD rQoq4fZRHs8WXWFOz7/YVWcdEnpqdJwU8DihQOEPGRVcsW1hPo2zH+yh8z5eH876P84t fejDFP0FouzDW+WbMTjSwHNaXu5Hauev6mDL+hii6paMz4WxbV4GNmkg2Z6MvX3rkTKG aaUoZJD9SOhcDeLV20+ZxjF6XQqJsOycTAr8Vayef83PAU/PkKUzQGqVlQqjmU3Tj/vu r3+g== X-Forwarded-Encrypted: i=1; AJvYcCX/X0JA6HD3H5ErUfjf1SAD6q/AVtLpWqz3/PrjtWNGBl6KXpWow1/tLEm/OrW+l/qKwpxYbU3yfwbZnaAjIr++ZAGO6N1FCqK/ujKtek5GpF8= X-Gm-Message-State: AOJu0YyGMyFDHoB2bZjbKlvjcWWSBmGJf0o0qJrnjjijrhyvlDYKIq+w RxoFKloHvYf8HjO3YviRqfAYlcwK+Xd1qo7tXFBVRxU6oWb9Azu/qM/UGQ== X-Google-Smtp-Source: AGHT+IHSboZkG39oFg224FW+5wEW5HiU3Arm7ftDoOcI6cPbirI3hP0DzB+QncMZS+QWj5Rwhr0ktw== X-Received: by 2002:a05:600c:1c91:b0:425:6043:a61b with SMTP id 5b1f17b1804b1-4264a41f636mr56061035e9.36.1720283463305; Sat, 06 Jul 2024 09:31:03 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a82e.dip0.t-ipconnect.de. [79.227.168.46]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3678e68a622sm11003719f8f.106.2024.07.06.09.31.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jul 2024 09:31:02 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Sat, 06 Jul 2024 15:49:56 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x32f.google.com 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 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:321445 Archived-At: Pip Cet writes: > I wonder how representative that is of actual workloads, though. It isn't, for sure :-). > It does appear mostly to be the cost of finalization, if I deactivate > that (and leak the memory instead!) it takes about 6.5 seconds on this > machine compared to ~9 on my main Emacs. Totally unscientific, of > course, I'm pretty sure I even updated my compiler since compiling > vanilla Emacs. Both use nativecomp. I think the same. I under the impression that probably many millions of bignums are used, each of which requires inter-thread communication and so on. That's quite expensive if true. > So IF it's worth optimizing this, the thing to look into would be to > use MPS-managed memory for GMP bignums, so we don't need a finalizer > at all. I think that's quite easy to do, but requires violating the > GMP API by accessing internal member fields directly. We have already this in bignum.c mp_set_memory_functions (xmalloc, xrealloc_for_gmp, xfree_for_gmp); Haven't read the GMP docs yet, but that looks like something that could be used. > I believe Eli is right, though, that we should deviate from what Emacs > usually does as little as possible until we've got things working. > That means just keeping track of how much we've allocated and calling > garbage_collect via maybe_garbage_collect, I think. Can you explain? I mean I agree in general, but in this case I'm not so sure. What I've currently implemented is basically a function of the number of allocated finalizable objects and only finalizable objects pay the price. The size of allocated memory overall, i.e. counting the bytes in alloc_impl doesn't contain the information. > As for memory usage, I wonder how much of that is MPS memory and how > much is simply the limbs of the bignums, which MPS doesn't know about. > My guess is pidgits uses large bignums, but MPS only sees the small > mpz_t allocations. Could be. Do we know the algorithm pidigits uses? Maybe one can find out if that uses large bignums.