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: GC thread performance Date: Sat, 02 Dec 2017 10:50:29 +0200 Message-ID: <87y3mltsx6.fsf@elektro.pacujo.net> References: <192F0231-DBB4-40D4-B3D6-0BAAB254CC59@telia.com> <87mv37z4q0.fsf@elektro.pacujo.net> <848C0138-B297-42C2-B45A-562176B88025@telia.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512204669 32577 195.159.176.226 (2 Dec 2017 08:51:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 08:51:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: Guile User , Hans =?utf-8?Q?=C3=85berg?= To: Linas Vepstas Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Dec 02 09:51:04 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 1eL3Vn-000804-KB for guile-user@m.gmane.org; Sat, 02 Dec 2017 09:51:03 +0100 Original-Received: from localhost ([::1]:34837 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eL3Vt-0003pV-4p for guile-user@m.gmane.org; Sat, 02 Dec 2017 03:51:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eL3VQ-0003pP-7b for guile-user@gnu.org; Sat, 02 Dec 2017 03:50:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eL3VN-0008M7-5v for guile-user@gnu.org; Sat, 02 Dec 2017 03:50:40 -0500 Original-Received: from lumo.pacujo.net ([185.87.111.179]:39530 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eL3VM-0008Gm-Tg for guile-user@gnu.org; Sat, 02 Dec 2017 03:50:37 -0500 Original-Received: from elektro.pacujo.net (192.168.2.7) by elektro.pacujo.net; Sat, 2 Dec 2017 10:50:29 +0200 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Sat, 02 Dec 2017 10:50:29 +0200 In-Reply-To: (Linas Vepstas's message of "Fri, 1 Dec 2017 13:49:35 -0600") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.87.111.179 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:14308 Archived-At: 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. Linux (at least) has locking primitives that have virtually no overhead when there is no contention. However, when there is contention, the context is switched to the kernel and a memory barrier causes the CPU hardware to flush its memory cache. The same issue hampers C developers as well, although the newest C standards explicitly shift to the coder the responsibility for the consistency of the data model. Thus, in principle, a C programmer can try clever tricks to eke out performance with multithreading. CPython has famously grappled with the same performance issues. The so-called GIL effectively turns every Python program into a single-threaded process. The point of multithreading is not a gain in performance. Rather, it is a programming paradigm to multiplex events. These and other issues with multithreading have caused many of us to reject multithreading as a paradigm altogether. Use event-driven programming for multiplexing and multiprocessing for performance. Marko