From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Experimental JIT for Guile (???!) Date: Tue, 04 Oct 2016 14:52:16 +0200 Message-ID: <87eg3w9szj.fsf@gnu.org> References: <87bmz91c9t.fsf@dustycloud.org> <1475035875.18187.50.camel@gmail.com> <87mvilnp7b.fsf@gnu.org> <87d1jh13ca.fsf@fimbulvetr.bsc.es> <87mvikfsud.fsf@gnu.org> <87mvikzba5.fsf@fimbulvetr.bsc.es> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1475587351 18049 195.159.176.226 (4 Oct 2016 13:22:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2016 13:22:31 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: Andy Wingo , Mark H Weaver , Atsuro Hoshino , guile-devel@gnu.org To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 04 15:22:25 2016 Return-path: Envelope-to: guile-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 1brPfg-0002Oq-4a for guile-devel@m.gmane.org; Tue, 04 Oct 2016 15:22:12 +0200 Original-Received: from localhost ([::1]:42478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brPfe-0000J6-Hs for guile-devel@m.gmane.org; Tue, 04 Oct 2016 09:22:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brPCo-00082T-Og for guile-devel@gnu.org; Tue, 04 Oct 2016 08:52:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brPCl-0001HX-4M for guile-devel@gnu.org; Tue, 04 Oct 2016 08:52:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brPCl-0001HO-1s; Tue, 04 Oct 2016 08:52:19 -0400 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:49726 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1brPCk-000459-61; Tue, 04 Oct 2016 08:52:18 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 13 =?utf-8?Q?Vend=C3=A9miaire?= an 225 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87mvikzba5.fsf@fimbulvetr.bsc.es> (=?utf-8?Q?=22Llu=C3=ADs?= Vilanova"'s message of "Tue, 04 Oct 2016 11:57:54 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18698 Archived-At: Hello! Llu=C3=ADs Vilanova skribis: > Ludovic Court=C3=A8s writes: > >> Hello! >> Llu=C3=ADs Vilanova skribis: > >>> Still, this mail made me think if optimizations based on "tracing" (or = any kind >>> of runtime-based profiling) could be nested. Then you could start by ap= plying >>> the existing compiler optimizations, later generate a procedure/trace v= ersion >>> dispatcher with unboxed operations (you can add new versions as they be= come >>> hot), and only at the end generate native code. > >> I=E2=80=99m not sure what you mean by =E2=80=9Cnested=E2=80=9D. What tr= acing JITs and Nash do >> is collect execution traces, and trigger native code compilation once a >> given segment of code (a loop body) has been executed a number of times. >> The generated code is specialized according to that trace. > > By nesting I mean applying different optimizations at different threshold= s, but > all based on tracing the executed code. Aka, the hotter it gets, the more= you > try to optimize it. > > Also, is it absolutely necessary to implement the tracing on the VM? Can'= t it be > done by adding a new opcode to the VM to compute the statistics? Then you= can > add that opcode to any region of code, like procedure or loop iteration > prologues. Also, then you can do so from a higher-level language that doe= s have > the concept of loops, instead of inferring them from jump offsets. Dunno. I like the hook approach because it=E2=80=99s very simple and orthogonal. From a Guile maintenance viewpoint, those hooks are something we can provide at no cost; conversely, providing a special opcode to gather traces would change a core aspect of Guile (the VM instruction set) and would be quite a commitment that we=E2=80=99d rather n= ot make. Disclaimer: I haven=E2=80=99t worked on this and Atsuro would know the answ= er better. :-) Ludo=E2=80=99.