From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Tue, 24 Dec 2024 06:38:10 +0100 Message-ID: <87y105od31.fsf@gmail.com> References: <87o713wwsi.fsf@telefonica.net> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <875xna6pnt.fsf@gmail.com> <87r05yax5a.fsf@protonmail.com> <87ttau5afi.fsf@gmail.com> <87msgmasx7.fsf@protonmail.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="34621"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 24 06:38:40 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 1tPxcu-0008v1-6K for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Dec 2024 06:38:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPxcd-0003qx-Vy; Tue, 24 Dec 2024 00:38:24 -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 1tPxcV-0003dx-Lh for emacs-devel@gnu.org; Tue, 24 Dec 2024 00:38:16 -0500 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPxcU-0005QG-4g; Tue, 24 Dec 2024 00:38:15 -0500 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d3d143376dso6848513a12.3; Mon, 23 Dec 2024 21:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735018692; x=1735623492; 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=kiZWEMJ/k5icC29LNivslJb/Y+Ftik5xS+5w4lHyuCY=; b=Py60WkpOBJ0IsaI+4MOw3lY9zwx6Q7cNcOqAjPw+yQPjZDtlEcWBtphDVWqzKuOKbD 0ZA9oUynVP42cDUbeAE62A+8UOeGBRfRenEUcaa3AWzsIUg+wk7pnS3PMfYWjy9GyPIM 5W9tMIztXATlwi9WOsYV+Y3elqj3JHR8O1fLhcrNDwFY0N8gbus5fVxp7f0+lK2BfIJp Vd135+ePTdBTVqlFsgJrsVFg9+Y2xI5mb/Fr7yCevxyNjkB2YOPvE97ARZxXKNP+MLKz xbdw2PxUNFsTll03vRLYnqnrJP/3GnMdltOh+QVfNlb6j7yEvV0eO0H/joIzYpH4bRic MT/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735018692; x=1735623492; 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=kiZWEMJ/k5icC29LNivslJb/Y+Ftik5xS+5w4lHyuCY=; b=Rx1lu8vRKfWEpT3/sJDE5ubTW4cTcRnh8E6JKSpR9O/AatuaLqi+As2VqN+JedYYZr lgf2vTdrI6OhUn2dxGNDo2Kk2q52fyjpc2PJMDcy5pQilVoCvTWoErGbA1SO9kmCFwEE vvJ+VZzAmdTzT4w2M0F4IyxdsyIWEyC9U3l5keP3q9j2lunhhT4CXkXnSu4Giuuk6Tue voO/hrAmP+jU7shK4nHNkoiWAOLC67AR7zOLBiZoFiZE5P5LNMRKnipIiSZIoiVGSXKQ H/BgJrgXy3QcUMki5QXatigBS7VsxbJ6QfI6ZeCFT7Io4PKmklTHqqnRN//LtGj6ZVED /HwA== X-Forwarded-Encrypted: i=1; AJvYcCW0prqVIQ3Iv88jl+xRuHKPMnY11qFZCHv5MkvGSQQ7PzoS9UDdg3ylsNCNJ935g8shDE1UxFzzdA==@gnu.org, AJvYcCX08EDnAyTpGRkBtGZvn2pnPaala+dv6bR9fw181RapKTCWq2JTLwHCxn2O6CL5ETn1EnHJySnA6SI433M=@gnu.org, AJvYcCXecXaFPgWH7Kkl6vejkra67860JZaYY5paLPpysZlOoZkSi0tFCdq+zHZ2b0KoxTBit0ooyg==@gnu.org X-Gm-Message-State: AOJu0YwAHi7D7vTkaQ7YiPDWc7fbKhVWtZ2DeAs98qjD2PTzj+YoHCeG M4Vd8qadS54fWy6MAhD16gE4zyQyW7rXEu55Hp/S2HyLMhwwfegZ782DbN2b X-Gm-Gg: ASbGncv11360dQDsYvF5PCyl8siH4fVMVINl++rXGZoWVTL6pqToUyIaR256ozia3zj 6nwXcmpFWd0GZrcoQPWZ1SUHUtHtub7veitJbr7zRY/hsjkvb1HtzMrdJQmga9dGpPj/fYknQr5 VxP3b0eFAqDC74UYmHybD1nJRRJrW7vC8E9+4awvX0QPWYPwsO7nmPfRvImM7+5uQcUxKE4lLhb GWwrDQlHHoCZcPUfBy2tEkjbfNnI2M95n9sjDhDdmFS7X9Cmebd2Ok= X-Google-Smtp-Source: AGHT+IGs8vtHknbTNNTo3FtkAwXXhSQxf15blZ1neIp5H3cdlGVqzdwmMSsQ8ScQiRWJZnRKBT1+kA== X-Received: by 2002:a05:6402:528a:b0:5d3:cdb3:a60 with SMTP id 4fb4d7f45d1cf-5d81de19972mr14504170a12.34.1735018691703; Mon, 23 Dec 2024 21:38:11 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80675a49fsm5705145a12.15.2024.12.23.21.38.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Dec 2024 21:38:11 -0800 (PST) In-Reply-To: <87msgmasx7.fsf@protonmail.com> (Pip Cet's message of "Mon, 23 Dec 2024 23:20:34 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=eller.helmut@gmail.com; helo=mail-ed1-x52b.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_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:326963 Archived-At: On Mon, Dec 23 2024, Pip Cet wrote: >> sxhash_eq doesn't fly with headerless objects. > > Which objects would that be? > > Right now all IGC objects have headers, right? Did I miss any? Right, but I'd like to keep that option on the table. >> It should be obsoleted, IMO. [...] > That leaves conses. My guess so far was that you wanted to implement a > hack where a headerless cons is a two-word object that would turn into a > tagged pointer to another two-word object with a header as soon as its > hash value is taken. That requires slowing down either XCAR or XCDR, I > think, and that's sufficient reason for me not to do it, but I guess I > misunderstood your plans. This would also mean sxhash_eq would allocate > memory, so it couldn't be called from a signal handler without yet > another workaround. I would go the obvious way: use segregated allocation. Each Lisp_Type gets its own MPS pool, without igc-headers. The dflt pool would only contain non-lisp types, like IGC_OBJ_STRING_DATA, with igc-headers. That wouldn't slow down XCAR, but it requires that hash tables use MPS's location dependencies. Helmut