From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Proposal: block-based vector allocator Date: Mon, 12 Dec 2011 11:24:13 -0500 Message-ID: References: <4EDDA68B.5050601@yandex.ru> <4EDE315E.3030804@yandex.ru> <4EDEF421.6090800@yandex.ru> <4EDF8F8E.8050401@yandex.ru> <87hb1b25i7.fsf@uwakimon.sk.tsukuba.ac.jp> <4EE03FFD.1090400@yandex.ru> <4EE0EA5C.1090505@yandex.ru> <4EE1CF09.70700@yandex.ru> <4EE23422.3050008@yandex.ru> <4EE56FE6.4050305@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323707075 2902 80.91.229.12 (12 Dec 2011 16:24:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Dec 2011 16:24:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 12 17:24:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ra8g2-0008Nh-Pc for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2011 17:24:31 +0100 Original-Received: from localhost ([::1]:34140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra8fz-0002zv-TT for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2011 11:24:27 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra8fs-0002zb-FS for emacs-devel@gnu.org; Mon, 12 Dec 2011 11:24:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ra8fo-0005gM-5W for emacs-devel@gnu.org; Mon, 12 Dec 2011 11:24:20 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:22606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra8fo-0005g6-2q for emacs-devel@gnu.org; Mon, 12 Dec 2011 11:24:16 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANkp5k5FxLI7/2dsb2JhbABDqDqCRYEGgXIBAQQBViMFCwsOBCISFBgNEBSIG7Uni20EiDGaNIRR X-IronPort-AV: E=Sophos;i="4.71,339,1320642000"; d="scan'208";a="151977634" Original-Received: from 69-196-178-59.dsl.teksavvy.com (HELO ceviche.home) ([69.196.178.59]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Dec 2011 11:24:14 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id F0DA5660D4; Mon, 12 Dec 2011 11:24:13 -0500 (EST) In-Reply-To: <4EE56FE6.4050305@yandex.ru> (Dmitry Antipov's message of "Mon, 12 Dec 2011 07:07:18 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:146671 Archived-At: >> Let us how it turns out. > Results for the byte-compile benchmark, an average of 16 runs: > CPU time spent in user mode, seconds > ----< configuration >----< 32bit >----< 64bit >---- > default, stack mark 74.07 84.87 > default, GCPROs 72.90 81.37 > patched, stack mark 71.35 81.57 > patched, GCPROs 70.16 82.18 > Peak heap utilization, KBytes > ----< configuration >----< 32bit >----< 64bit >---- > default, stack mark 41499 73651 > default, GCPROs 37918 65648 > patched, stack mark 38310 67169 > patched, GCPROs 38052 65730 > Total time spent in GC, seconds > ----< configuration >----< 32bit >----< 64bit >---- > default, stack mark 23.58 32.32 > default, GCPROs 21.94 30.43 > patched, stack mark 21.64 29.89 > patched, GCPROs 21.13 29.22 > Average time per GC, milliseconds > ----< configuration >----< 32bit >----< 64bit >---- > default, stack mark 27.62 36.03 > default, GCPROs 25.57 33.93 > patched, stack mark 25.22 33.34 > patched, GCPROs 24.63 32.57 Since most small differences are difficult to separate from noise (and are not important anyway), the summary from where I stand is that there's no substantial difference (CPU and memory wise) between your new code (with or without GCPROs) and the current code with GCPROs, whereas the current code with conservative stack scanning is a tiny bit slower and uses a non-negligible amount of extra space in peak usage. This confirms that the main issue is the mem_nodes. It would also be interesting to see how your new code performs in terms of fragmentation (i.e. average memory use for a long running interactive session), but it's very difficult to measure and I doubt we'd see much difference (other than the impact of mem_nodes of course). > on 64-bit. In terms of CPU usage, results are more interesting: 1% > worse for 64-bit case, but 3.8% better for 32-bit. The only > explanation I have for this effect is that an arithmetic used in > splitting/coalescing operations creates some pressure on the CPU in > 64-bit mode, but 32-bit version of the same code may be implicitly > executed in parallel by the 64-bit core. 64bit cores don't implicitly parallelize 32bit code to take advantage of the 64bit datapath. So that can't be the explanation. And register pressure is worse in the x86 architecture than in the amd64 architecture. > Due to this, I don't consider my 32-bit benchmark as fairly > representative - it should be done on a real 32-bit core and not in > 'compatibility mode' on 64-bit one. You misunderstand what is the "compatibility mode" of amd64 processors. Stefan