From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Concurrency, again Date: Tue, 25 Oct 2016 13:34:16 +0000 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <86k2dk77w6.fsf@molnjunk.nocrew.org> <9D64B8EA-DB52-413D-AE6A-264416C391F3@iotcl.com> <83int1g0s5.fsf@gnu.org> <83twckekqq.fsf@gnu.org> <83mvi9a3mh.fsf@gnu.org> <20161012165911.58437154@jabberwock.cb.piermont.com> <20161012173314.799d1dc5@jabberwock.cb.piermont.com> <8360owaj2s.fsf@gnu.org> <20161013092701.77461800@jabberwock.cb.piermont.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114e2a8e3f27c9053fb09123 X-Trace: blaine.gmane.org 1477402805 20494 195.159.176.226 (25 Oct 2016 13:40:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 13:40:05 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 15:39:58 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bz1wz-0001UO-JR for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 15:39:33 +0200 Original-Received: from localhost ([::1]:54565 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1x2-0000hf-12 for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 09:39:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz1s9-0005CO-Cp for emacs-devel@gnu.org; Tue, 25 Oct 2016 09:34:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz1s4-0001HA-NE for emacs-devel@gnu.org; Tue, 25 Oct 2016 09:34:33 -0400 Original-Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:36788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bz1s4-0001Gy-ER for emacs-devel@gnu.org; Tue, 25 Oct 2016 09:34:28 -0400 Original-Received: by mail-wm0-x22f.google.com with SMTP id b80so164194841wme.1 for ; Tue, 25 Oct 2016 06:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7uAS3JqPk1ls+gw+ul+LgKpiLmjxlJkIlJ7svcPBDgw=; b=QM4f9Cei9GMfaE26L9Zxs56FA+98cQ2FUFvVOJq4AfK0Sr2bNiqrYMm73tjOkSNf+/ xJGjb2ALoO28oiu0zFbrMaNwTQH5RwmKUdi2vqrqONpYZALnmhH8Xw/bLnuqdV3AU5j3 Kc+oj4Ta1K8sdA3I+H/3Jrgj3rAlVmQ9KaKCXGmTomFSEdpRP5MX6GgFK3s4NlICIbFv 267ZXvcZ1rVzT04t3fO4YJYc4pYUyrUeSqBWNOervu1QmqI0kePEe3OykfA5Q22dHuG6 yxiND9s6QGqGasMjmypy8ScbUOOdmuWcR5MAAWimSNPDH6QypLxn5AuWNRgT7B8tyXNh nOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7uAS3JqPk1ls+gw+ul+LgKpiLmjxlJkIlJ7svcPBDgw=; b=ZbkV0f5FnuSBSbJzAywllawNqmqbiAPViGia3PITKIpgnQ8BNsVrBYGzzCfu07mBBd 1+Ma/HYGDhCE7XJeKdgRtWTRcPNEHJxu/at1vJxPgKSZWObgVVRwCj6xqSKZi/vh3FBm Q9lzG3oQSqkq8X93SKNGglSJDgZgCRmiTaqIeJmuK7Gfdt2vauo8q3lSvCvK078ZHGRn MIPlAINZV1DoCrHLrht/pW93zrhdb8isBNumEXTrKiG5+eWvAcsTQm6kyggGG5ope4pt ERn/1TcjDNU6VblOtkluiVF5Y4HfxZ9XJUaQII+YrWcI5oUuf/i6c+1H94TdJ9dA7Iix BBew== X-Gm-Message-State: ABUngve2f1Iac1i2fxYh9okNb/yFi5XoMyZ+VjoGRwKowY5p5JK5zVammUqO6hBX31FimXH4Vro94iwoXnnWtQ== X-Received: by 10.28.191.3 with SMTP id p3mr3588631wmf.112.1477402467180; Tue, 25 Oct 2016 06:34:27 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:208760 Archived-At: --001a114e2a8e3f27c9053fb09123 Content-Type: text/plain; charset=UTF-8 Stefan Monnier schrieb am Do., 13. Okt. 2016 um 20:15 Uhr: > > I can't think of too many cases where existing Emacs Lisp would > immediately > > benefit from being massively parallel, either. > > I think the benefit only exists if we want to increasing the > functionality along with the available compute power. > > AFAIK single-thread performance has reached a plateau about ten years > ago and there's no sign of its end, and Emacs is "stuck" in > this plateau. Luckily for us, Emacs is far from the only one: very few > programs nowadays know how to take advantage of the extra compute power. > > But I see no way to make Emacs take much advantage of parallelism, other > than in completely separate tasks written in other languages > (e.g. a separate executable scanning all a project's files in parallel). > > All I was pointing out is that this discussion is about concurrency and > not parallelism. > And that's a very important distinction to make. I think most of the resistance to the concurrency branch in Emacs comes from the fact that it uses OS parallelism primitives such as threads and mutexes to implement cooperative concurrency. Parallelism indeed appears to be impossible for the foreseeable future; it would require almost a complete rewrite of Emacs. Cooperative concurrency, on the other hand, has a much more limited impact. I'd suggest to adapt the terminology accordingly: "thread" *can* of course mean "cooperative userland thread", but for most programmers it has come to mean "OS-level parallel thread with preemptive kernel-level scheduling". Should we avoid this term and use "coroutine" instead? --001a114e2a8e3f27c9053fb09123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Stefan= Monnier <monnier@iro.umontr= eal.ca> schrieb am Do., 13. Okt. 2016 um 20:15=C2=A0Uhr:
> I can't think of too many cases where= existing Emacs Lisp would immediately
> benefit from being massively parallel, either.

I think the benefit only exists if we want to increasing the
functionality along with the available compute power.

AFAIK single-thread performance has reached a plateau about ten years
ago and there's no sign of its end, and Emacs is "stuck" in this plateau.=C2=A0 Luckily for us, Emacs is far from the only one: very fe= w
programs nowadays know how to take advantage of the extra compute power.
But I see no way to make Emacs take much advantage of parallelism, other than in completely separate tasks written in other languages
(e.g. a separate executable scanning all a project's files in parallel)= .

All I was pointing out is that this discussion is about concurrency and
not parallelism.

An= d that's a very important distinction to make. I think most of the resi= stance to the concurrency branch in Emacs comes from the fact that it uses = OS parallelism primitives such as threads and mutexes to implement cooperat= ive concurrency.
Parallelism indeed appears to be impossible for = the foreseeable future; it would require almost a complete rewrite of Emacs= . Cooperative concurrency, on the other hand, has a much more limited impac= t.
I'd suggest to adapt the terminology accordingly: "th= read" *can* of course mean "cooperative userland thread", bu= t for most programmers it has come to mean "OS-level parallel thread w= ith preemptive kernel-level scheduling". Should we avoid this term and= use "coroutine" instead?
--001a114e2a8e3f27c9053fb09123--