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?Mattias_Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.devel Subject: Re: Question about bignum usage Date: Sat, 13 Jul 2024 11:43:40 +0200 Message-ID: <14CA211A-7795-4427-B3B3-870B6EB80108@gmail.com> References: <86frt8nn8b.fsf@gnu.org> <86ed8snk0p.fsf@gnu.org> <227390B1-09FC-4FD5-B9E9-2729624A0D13@gmail.com> <868qz0nd81.fsf@gnu.org> <1cbd7603-2185-4066-9e0f-a358daf28af1@cs.ucla.edu> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37386"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 13 11:44:36 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 1sSZIx-0009WN-WC for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jul 2024 11:44:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sSZIC-00061W-AB; Sat, 13 Jul 2024 05:43:48 -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 1sSZIB-00061J-4T for emacs-devel@gnu.org; Sat, 13 Jul 2024 05:43:47 -0400 Original-Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sSZI9-00069g-Ie; Sat, 13 Jul 2024 05:43:46 -0400 Original-Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2eeb2d60efbso32935571fa.1; Sat, 13 Jul 2024 02:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720863823; x=1721468623; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=zKTj++nATydEkHgJVWphBc7f6y91II+pS1/mFYhnD9c=; b=MZrFfKVWjqTqYjnczo5B9Sj6d1cELsktwZnGvQfmimBqSQoZN8LRdZXcoOAGxQFTXg MV53Rfk+3wwQSUL5ThTXU42Hg4vDIQ0KZpq0BZyd1vRa8t4k9rvu3di3WmX3MmpuMaNs YW7aw9ev7rGHJgT3VxNm5fg0ILGbhEucpN9v4vSjT82AyiBoxe7F9LXo4KM2QNSgdxAg SvbJ+wgkfuo0CoWE5LuTtZ7o+fQ+ZRWfLeh6AuBD5hTkg6PpF3oIxDMC7dQ0rVdepkFK x5Dc1MLOYUgtl/gM2BWJFPIWaC7awIOyiGMQ3oGsPmSf5DKi9qhWrP7yi8+E+MKgixEH qWZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720863823; x=1721468623; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zKTj++nATydEkHgJVWphBc7f6y91II+pS1/mFYhnD9c=; b=FshS64cAccRC3QF7at12wOCXS5VS423BLuJ85N3m91xuAZdU/rX87KJZFiZ679WNAv YQ0QaBv6JbssKKugkuG5egTyuvVFHYjvisFMJRXCdbS9WSA7wcMoIimVBWqL9jRla4VH zNh4smHy60ekkBxsfgiPvpaoMjbdgWuSx90VBLDGFANCgOHjITelpYNb/iueMg8j4Xio 4FF3Q1wgvyDKK96ebTDrtv1mVXrZL94VfdtzaNApA9koTVw5SjwRqax/Q5NqFEzG4U4w NlRysZAEHKNmZZwjuc2LRGJOh/EqhhSRe/Lzyy0JXYWgq4cW18WWHcyZKf5Ddrh4n3J0 dERw== X-Forwarded-Encrypted: i=1; AJvYcCUoOly2OsSLx8F2nOCpBqyghlzH7ZYz4GMlp+Re27vPQCRPU7xTov/8HfDAlK60CWmpR+jeMICCrd14ousY7y439x9z X-Gm-Message-State: AOJu0Yxv6AhFpaTJomzZQ17IE90O0q2igm+9f5TRSXmwlf9ZFQBmbhdx O7tzcTNzNhSceKlyPUu2MaMjLswrlcj1Ei0bzRp5wAdiCaEKOG6S X-Google-Smtp-Source: AGHT+IHoFgSJ7g1xW9gbe20G31JXWYT4wIbUNit/tKB9vGFIB/PoyjHrePewdhbdi4XL8W97aRyOAA== X-Received: by 2002:a2e:9695:0:b0:2eb:d924:43fb with SMTP id 38308e7fff4ca-2eeb31716f8mr90998181fa.41.1720863821678; Sat, 13 Jul 2024 02:43:41 -0700 (PDT) Original-Received: from smtpclient.apple (c188-150-191-82.bredband.tele2.se. [188.150.191.82]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2eee17ad2b8sm1463841fa.35.2024.07.13.02.43.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jul 2024 02:43:41 -0700 (PDT) In-Reply-To: <1cbd7603-2185-4066-9e0f-a358daf28af1@cs.ucla.edu> X-Mailer: Apple Mail (2.3654.120.0.1.15) Received-SPF: pass client-ip=2a00:1450:4864:20::22a; envelope-from=mattias.engdegard@gmail.com; helo=mail-lj1-x22a.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:321602 Archived-At: 11 juli 2024 kl. 16.10 skrev Paul Eggert : > I installed the attached. 0017 should should address the performance = problem with decode_timer. The other patches refactor and address some = related issues. That was a lot more ambitious than I had in mind, thank you! I pushed a tiny simplification. More can be done. For example, time = decoding output sometimes depends on the exact form of the input: (time-convert '(0 3) t) =3D> (3 . 1) (time-convert '(0 3 0) t) =3D> (3000000 . 1000000) (time-convert '(0 3 0 0) t) =3D> (3000000000000 . 1000000000000) Does it make sense to distinguish (A B), (A B 0) and (A B 0 0) like = this? Some kind of performance hack to keep denominators the same? > As I understand it decode_timer was the locus of the performance = issue. If other places are also involved, please let me know. It probably dealt with the most noticeable parts but the timer system = doesn't appear to be short on slow code. For example, does timer_check really need to duplicate the time queues = each time they are checked for an event to run, even if there isn't one? Not to mention the baroque time representation of `timer` objects and = the cost of time-less-p and (especially) timer--time-less-p. Can we make changes to the `timer` struct now? Apparently there were = some holdouts in 2012 (which is why the `psec` slot is where it is) but = there has to be a limit to how we have to support old badly written = code.