From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS image cache Date: Sun, 05 May 2024 18:49:55 +0300 Message-ID: <86ttjccl7g.fsf@gnu.org> References: <875xvvp3fo.fsf@gmail.com> <87o79n0wna.fsf@gmail.com> <86ikzseipz.fsf@gnu.org> <86bk5keev3.fsf@gnu.org> <867cg8ed56.fsf@gnu.org> <861q6ge4iy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.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 Sun May 05 17:50:16 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 1s3e80-0004Hx-55 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 May 2024 17:50:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3e7l-0007jK-0w; Sun, 05 May 2024 11:50:01 -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 1s3e7j-0007ia-VU for emacs-devel@gnu.org; Sun, 05 May 2024 11:50:00 -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 1s3e7j-0002rD-Ms; Sun, 05 May 2024 11:49:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=sjXLTiTafEmf4zmtyL80Zrh/G4OZtI8mxKKTwTki9Wo=; b=GWbF8rNaaFbsIBiQY+t1 SRQgOjao9Qgs2D5WKPQnmud83QdTi/BeY8WAn0MdZne/NRnta0fwcQXhRUFlKfZGv3/fL6VsWtOAy o1p/8lOuz+3kbhuUtc9k6MqVjGK3XK9dfM4l2Lg4/SP0ck+He9dDRHCZBxS+QI7ffAtMsHDEJzhh/ AfW7PqhQ6vxMSmrw2KJJW8sreGZ04ej7edfIY948RcVDZG/E2Jij5OJ4g6mBrFgtLGUIepbIe+2X3 CVPBisXg1OdsRTGxMsl23zX8PXMjx2nZnQl/7FioxPVmDGW+dVvXszelFt3Ua0qZyF1bgCG0Ybzz1 sFkmbum4mYCuTQ==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 05 May 2024 16:32:02 +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:318841 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Sun, 05 May 2024 16:32:02 +0200 > > I think it's a matter of personal priorities. It guess it can't hurt to > say explicity what these are. > > 1. Make progress fast, so that I can assess for myself if it's worth > continuing. With an Emacs up time of ca. 8h now, I tend to think so. > When it would reach say 5 days or so, we'd be in the realm of what > master survives for me on macOS. > > 2. Make it work for me in my personal fork (CL packages) which is macOS > only anyway, and is basically for me alone only. > > 3. GNU. And I'm neither a maintainer of anything, nor want to maintain > anything in the GNU sense. And my impression was that we are trying to advance on 3 most important Emacs platforms in parallel, with the purpose of adding this to Emacs at some point. Apologies for my misunderstanding. > >> >> We allocate a vector of N pointers. The N is found in the header when we > >> >> scan it. It's the size of the MPS object we scan minus the header > >> >> divided by how large a pointer is. > >> > > >> > OK, but why does the struct have to fit in a single word? > >> > >> It doesn't, it the other way around. I'm using nwords - 1 for the size > >> of the vector, and the static_assert is intended to fire if nwords - 1 > >> is not right. > > > > OK, then my question now is "why does it have to be nwords-1?" > > I suspect that I'll answer something you don't ask again: We allocate a > vector of N elements. We don't store N directly somewhere, but we have > an igc_header from which we can compute N. So I compute it as nwords - > 1. If that's not right, I static_assert, and leave it to the interested > party to do something. I fixed the code according to my understanding, please take a look and tell if I missed something (since the new function does not seem to be used yet for the two caches you mentioned, it is hard to know whether I violated some assumptions). Thanks.