From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: GC thread performance Date: Sat, 2 Dec 2017 14:30:50 +0000 Message-ID: <20171202143050.598f227d@dell.homenet> References: <192F0231-DBB4-40D4-B3D6-0BAAB254CC59@telia.com> <87mv37z4q0.fsf@elektro.pacujo.net> <848C0138-B297-42C2-B45A-562176B88025@telia.com> <87y3mltsx6.fsf@elektro.pacujo.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512225092 20096 195.159.176.226 (2 Dec 2017 14:31:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 14:31:32 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Dec 02 15:31:18 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 1eL8p2-0004PB-Ma for guile-user@m.gmane.org; Sat, 02 Dec 2017 15:31:16 +0100 Original-Received: from localhost ([::1]:35860 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eL8p9-0004Xi-Qh for guile-user@m.gmane.org; Sat, 02 Dec 2017 09:31:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eL8ol-0004Xd-RZ for guile-user@gnu.org; Sat, 02 Dec 2017 09:31:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eL8og-0006mK-UH for guile-user@gnu.org; Sat, 02 Dec 2017 09:30:59 -0500 Original-Received: from mail-wr0-x230.google.com ([2a00:1450:400c:c0c::230]:34325) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eL8og-0006ka-Mb for guile-user@gnu.org; Sat, 02 Dec 2017 09:30:54 -0500 Original-Received: by mail-wr0-x230.google.com with SMTP id y21so12805171wrc.1 for ; Sat, 02 Dec 2017 06:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=y7pUlUe8JdGlYvp40ftOhyguOQVLdeAvydo83FezTEo=; b=PgTNxy8K5QUAIi6nCIQv/cL1l1TUChQzzStsiDkUZgdAJmMIDwpWPPfEXugR5XKeX8 TvPqgfJXrBCGdGbtzpheMl54SsTTXMI42Ytq8h+aBb5mFB+8Ru5XDMPIrNqSVtqj8mFv uevHbkhzTiHVt0DaZXKtO5kzu+pC1qJlhnv9cDB6vtHSQ1yoF2DCJxFV7/Vd0jq12Eed AohDCtzp7USZEiSIrrkL3oQPdOZrzy/zHkIPpEQ3Zuy9YrAz7H36/EpbIkHpobZl1adZ LQINPFBV8Zq3BFN8BxhHhHO3PaDXNBWwE2ijEse8hbLUcWlyrji+E+MubbaGQgjMXezs oVDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=y7pUlUe8JdGlYvp40ftOhyguOQVLdeAvydo83FezTEo=; b=XILTnJ7NaSlDaJufgS3uBH7YBtqT6mQgWXbdcPWIO3Jp0Q00LFswLbvecFBjEe9gq9 CWFXjOyc35/mS2dA5fQvzSHMniKHhaM6aWdoWp+S377o6341+DgCeuFuwS4QARrg8zmC j/SWX56pFEAZ4eonnZYsVwQU533bL0WSqfDowGlIuPkjegOot0LGFWvGYywJX37QLqc7 2fH6y45xh5JgMZkEXlBJtTxUanBlHlUNqUtbXEfwV98cBf5mjSrXsg5AdKr+wgGvL9fy CuB1cMR2RS2VxQBv4np7k2U8g48fRyoZIffSCr1xQ54yHUDhLgB3kmJhRT4uJHKDvvR+ 67zw== X-Gm-Message-State: AJaThX4fQtqC83oLYxDcpaLt2aRYtRI6DqJgctYZwHzcBZgv+PeN7pxe /bSrrqF2+gkn0R0b/+l7I2OJAw== X-Google-Smtp-Source: AGs4zMZvJGW2M9fDtoDjA+s4oeHgsUPnr0rJPtRPYbuBJ+HLhQZMg3lNgvxU6j8f9CjS4nK803Hp9w== X-Received: by 10.223.160.61 with SMTP id k58mr7873931wrk.252.1512225052988; Sat, 02 Dec 2017 06:30:52 -0800 (PST) Original-Received: from dell.homenet ([84.92.156.209]) by smtp.gmail.com with ESMTPSA id m70sm3560098wma.36.2017.12.02.06.30.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Dec 2017 06:30:52 -0800 (PST) Original-Received: from dell.homenet (localhost [127.0.0.1]) by dell.homenet (Postfix) with ESMTP id 90B3E427E75 for ; Sat, 2 Dec 2017 14:30:50 +0000 (GMT) In-Reply-To: <87y3mltsx6.fsf@elektro.pacujo.net> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::230 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:14310 Archived-At: On Sat, 02 Dec 2017 10:50:29 +0200 Marko Rauhamaa wrote: > Linas Vepstas : > > I cannot speak to GC, but I freuqently encounter situations in guile > > where using the parallel constructs e.g. par-for-each, end up > > running slower than the single-threaded version. For example, using > > 2 or 3 threads, I get a 2x and 3x speedup, great, but using 4x > > gives a slowdown, often 10x slower than single-threaded. I try to > > make sure that the insides of the loop are large and long-running, > > so that the cost of creating and scheduling threads is > > inconsequential. > > > > I have not attempted to determine the cause of this, but basically, > > that entire subsystem needs a careful review and measurement. > > I'll have to speculate, too. > > Guile guarantees the consistency of the data model under all > circumstances. Bad synchronization between threads is allowed to cause > unspecified behavior, but it should never trigger a SIGSEGV. In > practice, that means excessive locking: all data access needs to take > place in a critical section. If you mean that you believe guile carries out significant and excessive locking to maintain the invariants of its containers and other SCM objects, I do not think that is right. I don't think guile generally does use locking for that: instead it uses the fact that SCM objects are stored in a type of size uintptr_t and aligned on 8-byte boundaries to enable pointer tagging (see the file tags.h in the source distribution). Guile can therefore leverage the fact that on any platform supported by guile threads, native pointer/integer types aligned on their natural size boundary are atomic, with in C11 terms relaxed (ie unsynchronized) memory ordering. guile is not going to carry out CAS-style or acquire/release synchronisation for you: a SCM object will be in a valid state but that state may be completely different from the one you expect if you don't synchronize in your own code. Guile may of course lock its own internal global non-fluid data, but that is a different point from the one I think you are making. As I recall, Andy Wingo was reporting in relation to his fibers library that it started to slow with more than about 8 native threads running. As I recall, after 8 native threads, significant improvements in speed failed to occur even with more than 8 processors. You are also likely to get a slow down if you run more native threads than you have processors. Chris