From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r110342: Count overruns when profiling; change units to ns. Date: Tue, 02 Oct 2012 13:52:40 -0700 Message-ID: <506B5418.8030506@cs.ucla.edu> References: <506B1850.1070404@cs.ucla.edu> <83wqz8ajra.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1349211198 20498 80.91.229.3 (2 Oct 2012 20:53:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Oct 2012 20:53:18 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 02 22:53:21 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TJ9SX-0001OG-Pi for ged-emacs-devel@m.gmane.org; Tue, 02 Oct 2012 22:52:53 +0200 Original-Received: from localhost ([::1]:54119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ9SS-0001Pp-5i for ged-emacs-devel@m.gmane.org; Tue, 02 Oct 2012 16:52:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ9SP-0001PZ-5P for emacs-devel@gnu.org; Tue, 02 Oct 2012 16:52:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJ9SO-0000PI-9S for emacs-devel@gnu.org; Tue, 02 Oct 2012 16:52:45 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:42230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJ9SM-0000P4-MV; Tue, 02 Oct 2012 16:52:42 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id A79C239E800E; Tue, 2 Oct 2012 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EypJ9hg1Vu8; Tue, 2 Oct 2012 13:52:41 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 3ABE439E8007; Tue, 2 Oct 2012 13:52:41 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 In-Reply-To: <83wqz8ajra.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153958 Archived-At: On 10/02/2012 10:03 AM, Eli Zaretskii wrote: > To see what interval is actually being loaded into the timer, one > needs to call getitimer after setitimer returns. Yes, that would have been an improvement. But it still wouldn't have been right, as on many platforms (including mine) the actual sampling interval differs from what timer_gettime / getitimer reports. With a CPU thread timer I can set the sampling interval to 1 ns (!), and timer_gettime reports that it's 1 ns, but it's actually ~1 ms because that's how thread scheduling works. I believe the behavior for this sort thing depends on which clock we're using, but I haven't investigated it further. > We can still translate that to time units, if we store the actual used > CPU time with each sample, not the count of the theoretical sampling > period. I believe on Posix systems this boils down to calling > clock_gettime with the correct timer ID Yes, that should help, but I expect it'd slow things down. On many hosts clock_gettime is reasonably slow because it involves a system call and whatnot. In particular the realtime clock can be a huge can of worms, due to multithreading and the desire to have a consistent clock across threads, stuff that we don't care about here but clock_gettime sometimes has to care about. More generally, there is often a performance penalty in trying to get the time precisely, and in profiling it's often more useful to get the time quickly than to get it precisely.