From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.user Subject: Re: out-of-control GC Date: Mon, 11 Sep 2017 01:38:30 +0300 Message-ID: <877ex6qivt.fsf@elektro.pacujo.net> References: <87zia28phj.fsf@web.de> <87shfuqojf.fsf@elektro.pacujo.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1505083172 29052 195.159.176.226 (10 Sep 2017 22:39:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Sep 2017 22:39:32 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: "guile-user@gnu.org" To: Linas Vepstas Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Sep 11 00:39:26 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drAsR-0005sF-6m for guile-user@m.gmane.org; Mon, 11 Sep 2017 00:38:55 +0200 Original-Received: from localhost ([::1]:54493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drAsY-0000qR-Bb for guile-user@m.gmane.org; Sun, 10 Sep 2017 18:39:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drAs6-0000q0-UA for guile-user@gnu.org; Sun, 10 Sep 2017 18:38:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drAs5-0007vX-NR for guile-user@gnu.org; Sun, 10 Sep 2017 18:38:34 -0400 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=48374 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drAs5-0007uT-FZ for guile-user@gnu.org; Sun, 10 Sep 2017 18:38:33 -0400 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Mon, 11 Sep 2017 01:38:30 +0300 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Mon, 11 Sep 2017 01:38:30 +0300 In-Reply-To: (Linas Vepstas's message of "Sun, 10 Sep 2017 16:47:09 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:14112 Archived-At: Linas Vepstas : > On Sun, Sep 10, 2017 at 3:36 PM, Marko Rauhamaa wrote: > >> Linas Vepstas : >> > which suggests that the vast majority of time is spent in GC, and not >> > in either scheme/guile, or my wrapped c++ code. >> >> That may well be normal. > > It might be "normal", but its objectionable. If 90% of the cpu time is > spent in GC, and almost nothing at all was actually collected, then > its too much. Hard to say. I don't know how much garbage Guile generates as part of its normal execution model, but for example Python generates garbage with each method call. It is very natural for each application of a Lisp function to create a throw-away data structure through substitution. > On the Amazon cloud, you get to pay by the minute. On laptops with > batteries, people complain. Especially when they are apple users, not > linux users. GC overhead is like RAM cache overhead or C function call overhead. Its the price of doing business. > If the compute job takes a week, and your user has discovered this GC > thing, then the user will conclude that it should take less than 24 > hours, and will tell you that you are stupid, and that guile sucks. I > have been told I'm stupid, and that guile sucks too many times. > > CPU cycles aren't free. I have no idea how good Guile's performance is. Python's performance is probably about 100 times worse than C, yet it's the fast becoming the most popular programming language in the world. Not everything in the world is done for performance. The #1 purpose for a programming language is managing complexity. Relatively few computation tasks require excellent performance, and there are other programming languages for that: C, C++, Java, C#, go Note that Java, C# and go are performant despite GC. GC generally doesn't have to be all that costly throughput-wise. The biggest performance drain for high-level programming languages such as Scheme or Python is the absence of compile-time typing. In fact, Python is adding optional static type annotation (which I'm afraid might be a big mistake). > However, guile uses gc_malloc_atomic for these strings, and so GC > should never-ever peer into the contents of them. So I don't think its > "accidental heap addresses". Its probably fragmentation, and the very > heavy churn of large malloc chunks. You aren't thrashing by any chance...? > So let me redirect: is there some central spot within guile, where the > decision to run GC is made? If so, what file would that be in? If not, > is there some string I should grep for? I believe that decision is left for GC_malloc(1L): GC_malloc will attempt to reclaim inaccessible space automatically by invoking a conservative garbage collector at appropriate points. Marko