From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: William ML Leslie Newsgroups: gmane.lisp.guile.devel Subject: Re: New feature proposal: Support C-code inline? Date: Tue, 26 Apr 2011 20:11:15 +1000 Message-ID: References: <1303293013.2749.41.camel@Renee-desktop> <1303532648.3575.8.camel@Renee-desktop> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1303812686 8211 80.91.229.12 (26 Apr 2011 10:11:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 26 Apr 2011 10:11:26 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 26 12:11:22 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QEfEn-0004QV-K5 for guile-devel@m.gmane.org; Tue, 26 Apr 2011 12:11:21 +0200 Original-Received: from localhost ([::1]:52965 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEfEn-0007h0-24 for guile-devel@m.gmane.org; Tue, 26 Apr 2011 06:11:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEfEl-0007go-2w for guile-devel@gnu.org; Tue, 26 Apr 2011 06:11:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QEfEj-000799-Um for guile-devel@gnu.org; Tue, 26 Apr 2011 06:11:19 -0400 Original-Received: from mail-fx0-f41.google.com ([209.85.161.41]:55071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QEfEj-00078v-QX for guile-devel@gnu.org; Tue, 26 Apr 2011 06:11:17 -0400 Original-Received: by fxm18 with SMTP id 18so397696fxm.0 for ; Tue, 26 Apr 2011 03:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JcKmzSEXvRJzZYwlw+h1TG+CJK3SsCUkYo7g3q2sLDc=; b=L9re4N+HKA1R/clwCC6gv9m7S0s5G+6fwPtih4hXynmq43KjWlffwuIDVjirTrS/BB hYC3ebWccXkPO9mxt3hSy87YG6xC1Z9PR5xnxDUOdaFYp94g6rZF3bOMXWLXtawiQGZq Hdwbp1j734P7L8dIkZkDj8CdngGix7Viitkbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=h00wjaWdqebOcUfT0anqnuOeL3Mido7hwQ93AgjU41qORVqrZ6OkPp5yaDrfHRfqQJ qDWF9YWIxILgal3NQUosCkiylBEOhZt7ZzkgKRE+6QKr6Vs8CDcZjmYNObOjPs/MqEj2 +gfedHwFdWiF54oVrEONslz3L3F1JJOrTYPos= Original-Received: by 10.223.14.22 with SMTP id e22mr637745faa.64.1303812675903; Tue, 26 Apr 2011 03:11:15 -0700 (PDT) Original-Received: by 10.223.72.206 with HTTP; Tue, 26 Apr 2011 03:11:15 -0700 (PDT) In-Reply-To: <1303532648.3575.8.camel@Renee-desktop> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.161.41 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12351 Archived-At: On 23 April 2011 14:24, nalaginrut wrote: > I think this simple solution could be a temporary substitute before a > AOT guile-compiler come out. To myself, I really want to use a AOT > compiler to do such a job(it's better for optimizing the code). Just to clear up a seemingly common misconception. Those writing an aggressively optimising compiler like to see two things: 0. Information. The more code you can see at a time the better, as it enables you to see how functions are used; you can see this in whole-program AOT compilers and modern JIT compilers such as hotspot, which inlines very aggressively in order to obtain more data. Information about the data these functions get applied to can be useful as well, as can be seen from high-quality SQL query plan optimisers, and the latest linear algebra libraries. 1. Room to breathe. Once the language semantics are specified and what effects are user-visible can be determined, the rest of the universe is room to optimise! For example, memory models are now often chosen as a balance between sensible semantics for the programmer and behaviour that has small enough impact on the runtime. Now, the effect that these points are having on modern compiler and runtime design should tend towards: * AOT will get you half way there. In embedded systems it may be entirely suitable, but those environments are also the ones where whole-program compilation is possible. Where separate compilation is desired, there are often more opportunities to optimise as dependent modules are compiled, and even more opportunities once the working-set and cache size, typical loop bounds, branch popularity etc can be discovered, and many of these things may change across different program inputs, so static compilation is unlikely to reach the quality of code that dynamic compilation provides. * Where calls into unsafe code occur, the semantics of the operation are entirely unknown. Thus the optimiser needs to assume that the code may do absolutely anything it pleases. It can mean that what might have been loop invariant or heavily partially evaluated cannot be. To consider the impact that this actually has, the value bound to a symbol in the current module cannot be assumed to be constant across an external call, preventing inlining pretty much everywhere. What occasionally happens is that code written entirely within the language that a smart runtime is able to inspect tends to be faster than that which is in idiomatic C. -- William Leslie