From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Compiling Elisp to a native code with a GCC plugin Date: Tue, 14 Sep 2010 13:32:30 -0600 Message-ID: References: <87bp805ecr.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1284492773 14493 80.91.229.12 (14 Sep 2010 19:32:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Sep 2010 19:32:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Wojciech Meyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 14 21:32:52 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OvbFD-0008Id-KD for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 21:32:43 +0200 Original-Received: from localhost ([127.0.0.1]:35500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvbFC-0002Mk-PP for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 15:32:42 -0400 Original-Received: from [140.186.70.92] (port=58785 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvbF7-0002MR-2t for emacs-devel@gnu.org; Tue, 14 Sep 2010 15:32:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvbF5-0008VR-QV for emacs-devel@gnu.org; Tue, 14 Sep 2010 15:32:36 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:36692) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvbF5-0008VB-II for emacs-devel@gnu.org; Tue, 14 Sep 2010 15:32:35 -0400 Original-Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8EJWXkD015029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Sep 2010 15:32:33 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8EJWWa2005175; Tue, 14 Sep 2010 15:32:32 -0400 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o8EJWVi1007039; Tue, 14 Sep 2010 15:32:31 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 3CE053784BE; Tue, 14 Sep 2010 13:32:31 -0600 (MDT) X-Attribution: Tom In-Reply-To: <87bp805ecr.fsf@gmail.com> (Wojciech Meyer's message of "Tue, 14 Sep 2010 20:12:20 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130146 Archived-At: >>>>> "Wojciech" == Wojciech Meyer writes: Wojciech> Recent version of GCC allow developing plugins. That would Wojciech> solve JITing intermediate representation (e.g. current Wojciech> bytecode) to the native code across different platforms. What Wojciech> do you think about it? Would that be possible or there might Wojciech> be some problems that would make it impossible (I am talking Wojciech> especially about dynamic scoping and GC interaction). I think you can compile elisp without needing a plugin. Just convert the bytecode to C, and compile that. This is actually quite easy. However, it is not very likely to result in a performance improvement right now. A similar idea was tried and did not work out: http://www.mundell.ukfsn.org/native/ I think this idea might be worth revisiting when lexbind is merged in, emphasis on "might". E.g., it seems to me that this approach might work ok for the recently-discussed range-map code. As I recall, in my profiles, the GC and the regexp matcher were more costly the bytecode interpreter (though of course this is workload-dependent). If you are interested in performance, I suggest doing your own profiles and starting there. Tom