From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Lightning Bindings Date: Tue, 01 Jun 2010 21:24:11 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1275462594 24768 80.91.229.12 (2 Jun 2010 07:09:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Jun 2010 07:09:54 +0000 (UTC) Cc: guile-devel@gnu.org To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jun 02 09:09:53 2010 connect(): No such file or directory Return-path: Envelope-to: guile-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 1OJi5I-0008B9-C4 for guile-devel@m.gmane.org; Wed, 02 Jun 2010 09:09:52 +0200 Original-Received: from localhost ([127.0.0.1]:50047 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJi5H-00087R-Lm for guile-devel@m.gmane.org; Wed, 02 Jun 2010 03:09:51 -0400 Original-Received: from [140.186.70.92] (port=36880 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJi58-00084B-97 for guile-devel@gnu.org; Wed, 02 Jun 2010 03:09:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJi57-0001SE-0w for guile-devel@gnu.org; Wed, 02 Jun 2010 03:09:42 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:41351 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJi56-0001SA-Sx for guile-devel@gnu.org; Wed, 02 Jun 2010 03:09:40 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id CB63FB8F5B; Wed, 2 Jun 2010 03:09:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=aLVAGBGxKxJLk4MO/HXPHGU0kaQ=; b=twnuWg tcmSVxeWvSdqIvN2xuOT1YpGJ5YxCEYXAgoyGbG9avfVYI+vr6OtuElxoSqsVQPd HofBwc/QQmgAFSd+TUbyj57LaXYBLlfqEiVC4DDioxvJJdhjRMInZtKPK7CYsMxQ jxmnVB3pv/jUDLhujgAgkvSidYU3QOFynSCXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=YjRP4YeMg+h+g+8KnPvrniVHPc1ds8zB 6wJpLXub3zeT9j6UyuP/Fgkl6Hi9Fq0cSFaIwRj0Fa4E82RNcqQNA0XlqWkUR1Gt xTnDd7Ej410AyJRg52+6+tXV24Avdjh05DzHzRWK2Rnzu2nWOftIB2SI025GYjv9 0anS2h9B9S4= Original-Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B778BB8F59; Wed, 2 Jun 2010 03:09:39 -0400 (EDT) Original-Received: from unquote (unknown [80.24.4.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id E524FB8F58; Wed, 2 Jun 2010 03:09:37 -0400 (EDT) In-Reply-To: (Noah Lavine's message of "Tue, 1 Jun 2010 10:55:06 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: CF634F64-6E15-11DF-A290-6730EE7EF46B-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10421 Archived-At: Greets, On Tue 01 Jun 2010 16:55, Noah Lavine writes: >> I tend to think that Ludovic's proposal, or something like it, is the >> most practical means to get a portable JIT compiler going; though I >> don't really know. > > You may be right; although I think actually with the FFI, it would be > just as easy to get it going in Scheme. To an extent, yes; but there are two problems that I see. One is the performance difference between implementing JIT compilation in Scheme versus implementing it in C. To an extent we're able to be somewhat wasteful in the compiler because it's all pre-computation, and it's not necessary to load up the compiler at runtime. But having to load a Scheme compiler at runtime for programs that don't invoke the compiler has a space-and-time penalty. Furthermore, one would be jitting the /compiler/ too, which is a needless timesink when you want to make your /program/ faster. Secondly, foreign functions are not called in tail context relative to the VM. Tail-calling a foreign function that tail-calls a Scheme function that tail-calls a foreign function consumes stack space. You need architecture-specific hooks within the VM itself to be able to tail-call a foreign function; and necessarily so, as they have different calling conventions. As long as you're mucking about on that level, it's almost easier to implement in C directly. I could be wrong of course; let me know if I'm not understanding you correctly :) > According to the docs, right now Scheme code can access any function > in the Guile binary - including the functions that implement the VM > instructions. Many VM ops are implemented inline; and especially, the ops that handle control flow (function calls, prompts, etc). > I think we might ultimately not want to be generating machine code for > each procedure, because that would make it impossible to do tracing > optimizations like current JavaScript engines (if I understand the > proposal right) This is true. However I think that compiling Scheme and compiling JS are a bit different; Scheme is much more amenable to ahead-of-time compilation, and less polymorphic. A proper inliner can catch many "trace trees" at compile time, and function calls are typically implemented much more efficiently than in JS (I hear SpiderMonkey has activation records that use ~30 words!). So I would not expect trace trees in Scheme to be as beneficial as it is in JS. > and also because that might lead to generating a lot > of machine code for non-bottleneck points just to get at one > bottleneck. Hm, I'm not sure what you mean here; can you explain? > I don't think this is something we should try to implement > now, but it'd be nice if the code generation infrastructure was > flexible enough that it could be added on later. Flexibility is very important, yes! > Your earlier thread asked how to get native code generation for Guile > in such a way that it didn't make Guile too big to understand. I think > a good choice would be to *not* put code generation in the core of > Guile. I agree with you in the ahead-of-time case. The "languages" in the compiler are modules that are lazily loaded; a native-code compiler would be a module with a "language" interface, and as such would only be loaded when the user requests native compilation (through various means). For the JIT case, the argument is almost convincing enough for me not to want a JIT at all! But if it can be done minimally and cleanly in C, the mental costs might be worth it. > [Native compilation only via a loadable module] has two advantages - > first, it makes core Guile small. Perhaps people who do embedded > systems would appreciate that, or who want to embed Guile in their > programs and care more about small code size than incredible speed. Embedded people are a strange crowd ;) On the one hand there's my N900 with 64GB of storage, which is practically a desktop to itself. On the other there's 12-bit microprocessors that only PicoBIT is appropriate for. We should certainly be able to disable the jit as a compile option, if it's implemented in C; for some people the small code-size of bytecode is really paramount. For some people they still want speed, so cross-compiled AOT native code is best, while omitting the native-code compiler on the target. For people with severe constraints, sometimes other Scheme systems will serve them best. Chibi seems fine, for example. Given all the constraints though, from a performance and size perspective I'm still inclined to do a stupid-but-fast-and-small JIT in C, and a smarter AOT compiler in Scheme. YMMV, of course :) > When I was looking at options earlier, I thought that GCC would be the > ideal, but it would be too hard to use their stuff. If they're willing > to work on this, then probably that would be best. Yeah agreed. I think we'll have to do a lot of social hacking to get what we want, but socially and technically this would be the best solution. >> I would be very interested in your observations, yes :) > > Well, here are some thoughts on existing work that we might be able to > reuse: Thanks for these observations! I'll chew on them over time :) Cheers, Andy -- http://wingolog.org/