From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Max Nikulin Newsgroups: gmane.emacs.devel Subject: Re: Time resolution in Emacs Date: Fri, 29 Apr 2022 22:19:10 +0700 Message-ID: <2a163573-c53a-910c-4dec-4742c91336ed@gmail.com> References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu> <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> <83tuapvcxs.fsf@gnu.org> <6efc5d24-34a2-fd30-cd20-fe4ac3e48310@cs.ucla.edu> <83fsm8tdzl.fsf@gnu.org> <9e4781b2-2ffa-b1ce-09b4-ead82cad9038@cs.ucla.edu> <83ilr3siku.fsf@gnu.org> <4e41671c-fae8-61c4-845c-4c7ba4317e88@cs.ucla.edu> <83fsm7sh2s.fsf@gnu.org> <83czhbsgc2.fsf@gnu.org> <33fb24fb-282b-cc13-a597-e7b63f19982d@cs.ucla.edu> <83y1zzq6kd.fsf@gnu.org> <837d7hr8s3.fsf@gnu.org> <83h76kq5c6.fsf@gnu.org> <9afbcc3d-b57c-b5bf-e4f6-52b352f99af8@cs.ucla.edu> <83bkwspa1r.fsf@gnu.org> <3008dea1-572b-9010-f3c4-15272145fd8a@cs.ucla.edu> <7ae621ed-d03b-00cd-bfb3-04a4a2a7d5ce@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7543"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 29 17:41:12 2022 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 1nkSk4-0001lB-8t for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Apr 2022 17:41:12 +0200 Original-Received: from localhost ([::1]:40788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkSk3-00045b-6t for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Apr 2022 11:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkSOr-00027q-7k for emacs-devel@gnu.org; Fri, 29 Apr 2022 11:19:17 -0400 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:33371) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkSOp-0005V1-Dt; Fri, 29 Apr 2022 11:19:16 -0400 Original-Received: by mail-lf1-x131.google.com with SMTP id bu29so14711205lfb.0; Fri, 29 Apr 2022 08:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=URcP+WO6bISOJLCnrIDeX7uERukxb36a1tU3o24oWgk=; b=MFuZv8QRh8D849Luh1onpbGHR9x6jyAv8rc/AVCKbxQpjIVyNRJOXyJmLm335DjhqL MKpW2kFyoOX02+FnIx4Vt/qfOTshhfgQpLIHgACyvev8kpzOxqx5QtBlNTVSibtC6azM 8OrNFE/jzc9HP8taPlGjNAL7GIh7XDHxxHb/9GDolsoNpSv1K19fuoQ2PNd4tULAqjtN cJYW55zBFdLZlVqthjG2j8BZfnc6Nr5YRtoTzNO1GP0pEU+HukWmS78aZUSjiCKGamp2 BS2BQFLmrpladPKdxPPVQ8uBcVGg/FgORePO5F7pZQynE54I5iBO5fhn7MI9ak2auCrs nOig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=URcP+WO6bISOJLCnrIDeX7uERukxb36a1tU3o24oWgk=; b=L2amfMemeC/7Msw6jDU2/dRjQd+IKMr5deXxPBlGSqjukNq/NNHeC92Ejwv8V9E4sp ZEeCCUVTRQTeL2BlJIERaZ+zN61h0AopbuA25S1m9IqIPwdMOREtqpL1ZXu7YEKVxG3P eBc3rqy/F6b9f+xske1iZ7/4E8g6vkGzAxH/rKt6cYjF2wUVYN2TE4ENgR2GfNAOsi7L XscCVJa/alg5WXmCHEbRJtaDkds03sij1xlCnEdOSshS/4uBbDw/tC2EUwcVEfHZib6v f4BG8ARaT5fk3nrpUaf494vKh+Bc+vlx5RCKOQXWr7j9yfn3UKXxaT4Sbis+rnRIXWrP hbsg== X-Gm-Message-State: AOAM5305Ug0yQ9AGOmI6Boy1Fq402JI3cWaarqRmlasWIJ7wFEh3F9rK veraDSgfBnc9Nn4zRBrhb3DuPY+SxrM= X-Google-Smtp-Source: ABdhPJx/pNFz2zCRHSBaXZuGppLJr/B9mwPVq2Z1Mpm9jlGVUGowxIua9zXO4714Ztqp6DZc736YKQ== X-Received: by 2002:ac2:4ac9:0:b0:471:f6da:640d with SMTP id m9-20020ac24ac9000000b00471f6da640dmr23200746lfp.286.1651245552399; Fri, 29 Apr 2022 08:19:12 -0700 (PDT) Original-Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id bd6-20020a05651c168600b0024f3d1daeb5sm288257ljb.61.2022.04.29.08.19.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 08:19:11 -0700 (PDT) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=manikulin@gmail.com; helo=mail-lf1-x131.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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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" Xref: news.gmane.io gmane.emacs.devel:289000 Archived-At: On 26/04/2022 02:27, Paul Eggert wrote: > On 4/25/22 09:54, Max Nikulin wrote: > >> on Linux while file metadata are in cache, timestamps may have high >> time resolution. When later fetched from disk they may have coarse >> resolution, e.g. whole seconds. > > Yes, that is a known bug in older Linux kernels. As I understand it, the > bug was fixed many years ago. (It broke GCC builds circa 2004[1] so > there was a good deal of motivation to fix it.) I expect this problem is > no longer relevant; if I'm wrong, Eli's suggestion would help to work > around it. > > [1]: > https://linux.kernel.narkive.com/XLtQbTzQ/linux-2-6-nanosecond-time-stamp-weirdness-breaks-gcc-build Thank you. I do not remember why I was aware of such peculiarity and considered it as a feature. I have not expected that it was fixed. Accidentally I have found the following proposal to add fsinfo() system call to the Linux kernel. It should expose timestamp resolution, but likely the patches was not merged. I have not read the discussion though. https://lwn.net/Articles/827934/ David Howells VFS: Filesystem information [ver #21] Mon, 03 Aug 2020 14:36:21 +0100 On 26/04/2022 00:02, Eli Zaretskii wrote: >> Date: Mon, 25 Apr 2022 23:54:58 +0700 >> From: Max Nikulin > >> As to 16ms resolution, at least for `benchmark-run' I would like to have >> finer granularity. > > Do you really run benchmarks that end in a matter of milliseconds? It may be enough for quick estimations during comparison of methods having order of magnitude difference in running time. Sometimes it is necessary to measure duration of particular calls without repetition. > In any case, measuring a time interval with high precision doesn't > necessarily need a fine-granular wall clock. My experience is that it is even less probable to find monotonic clock or performance counters implemented when some legacy method is used for wall time.